[9.2.2] Error when XD Packaging

Hi,

I am getting these 5 errors logged to the Transcript when dumping an XD Packaged image to Disk:

Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.

The runtime image seems to be fine, at least we haven't found any problems with it since we package on 9.2.2 and see these errors. They don't show up in 9.1, even though they use the same library.

What should I look for?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b55b482a-8d4b-47b9-a575-b312412c2bean%40googlegroups.com.

Hi Joacim, 

This doesn't seem to be something common (only one old case appeared in our case database). First, a few questions:

1) You said you are using the same library for 91 and 922 but, but which emsrv are you using now? same for both or the emsrv shipped with each VAST version? 

2) Is there any bitness difference between 91 and 922 (for example, was 91 32 bits and now 922 is 64?)

3) Our gut feeling is that you have a corrupted library object stored in your manger. If I were you I would debug the following

LibraryObjects class>>loadRecord:using:ifAbsent:

where loader hasErrorOccurred is true and see what library object it is

4) You may also try to shrink/compact/clone your existing manager (just to give it a try, don't delete the original one). You can do this from Tools -> System -> Clone Library. You will loose scratch editions etc so be sure not to remove the original manager. This is more a test than anything else. 

Best, 

On Mon, Aug 3, 2020 at 10:40 AM Joachim Tuchel <[hidden email]> wrote:

Hi,

I am getting these 5 errors logged to the Transcript when dumping an XD Packaged image to Disk:

Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.

The runtime image seems to be fine, at least we haven't found any problems with it since we package on 9.2.2 and see these errors. They don't show up in 9.1, even though they use the same library.

What should I look for?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b55b482a-8d4b-47b9-a575-b312412c2bean%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

3) Our gut feeling is that you have a corrupted library object stored in your manger. If I were you I would debug the following

LibraryObjects class>>loadRecord:using:ifAbsent:

where loader hasErrorOccurred is true and see what library object it is

Hi Mariano,

thanks for checking.

I had indeed forgotten to change my emsrv.services file to use the latest emsrv of Version 9.2.2. But using the latest one didn't remove the error, unfortunately.

I've been using the library with 9.1 with 64 bits exclusively, and I am also only running 64 bit images with 9.2, but the library is much much older and has been used with 8.6 and older with 32 bits images

What's funny is that I cannot find any methods including String "Invalid array of input buffers' - neither in the active nor the passive image (Linux 64 bits). And there are no references to 172 in them. So where does this error come from? Is it generated by EMSRV?

The Clone Library job is running at the moment. So I'll be back with more news later today.

Joachim

[hidden email] schrieb am Dienstag, 4. August 2020 um 14:42:27 UTC+2:

Hi Joacim, 

This doesn't seem to be something common (only one old case appeared in our case database). First, a few questions:

1) You said you are using the same library for 91 and 922 but, but which emsrv are you using now? same for both or the emsrv shipped with each VAST version? 

2) Is there any bitness difference between 91 and 922 (for example, was 91 32 bits and now 922 is 64?)

3) Our gut feeling is that you have a corrupted library object stored in your manger. If I were you I would debug the following

LibraryObjects class>>loadRecord:using:ifAbsent:

where loader hasErrorOccurred is true and see what library object it is

4) You may also try to shrink/compact/clone your existing manager (just to give it a try, don't delete the original one). You can do this from Tools -> System -> Clone Library. You will loose scratch editions etc so be sure not to remove the original manager. This is more a test than anything else. 

Best, 

On Mon, Aug 3, 2020 at 10:40 AM Joachim Tuchel <[hidden email]> wrote:

Hi,

I am getting these 5 errors logged to the Transcript when dumping an XD Packaged image to Disk:

Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.
Error: 172   An error has occurred reading an object from the library. The error message is: Internal Error: Invalid array of input buffers.

The runtime image seems to be fine, at least we haven't found any problems with it since we package on 9.2.2 and see these errors. They don't show up in 9.1, even though they use the same library.

What should I look for?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b55b482a-8d4b-47b9-a575-b312412c2bean%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

Okay, I think I found the problem....

The passive image on Windows that packaged without errors had different properties than the one in Linux.

While the Windows Image only had "Database - Glorp, DB2 CLI", the Linux one which showed the errors also had "Database - DB2 CLI" loaded. When I created a new passive Image without "Database - DB2 CLI", packaging and dumping a headless runtime image works without the errors.

How did I find out?

I put the breakpoint in the active image as Mariano suggested and saw things like this:

LibraryObjects class>>#loadRecord:using:ifAbsent:
    self=LibraryObjects
    aRecord=#EmRecord: 'some String with NUL bytes in it'

    loader=an ObjectLoader
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
    answer=nil
AbtNlsKernelApp class[UNIX](Class)>>#objectNamed:in:ifAbsent:
    self=AbtNlsKernelApp[UNIX]
    aName='$AbtNlsPoolDirectory$'
    anApp=AbtNlsKernelApp[UNIX]
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
[] in AbtNlsDbg class>>#recordNlsPoolNames:
    self=AbtNlsDbg
    anImage=an EpRomerImage
    poolNames=Set(#AbtOdbcPlatformFunctions )
    app=AbtNlsKernelApp[UNIX]
    names=nil

Which somehow told me I need to take a look at the packeged Image contents and see if I find something interesting. Which I didn't. Which to me sounds logical, since the Packaging Instructions are the same in both teh Windows and the Linux image.
So the idea was to see what else could make a difference between the two images. If I load the same Packaging Instructions and the same Config Maps on both images, there must be something different "below" my code. Since both images access the same Library on the same Linux machine and use the same EMSRV, the only differende is either in my base image(s) or some code shipped by Instantiations - that was my idea. So I took a look at the passive image properties and found the differenve mentioned above.

Now I am happily packaging my headless image on Linux (where automation works much better than on Windows and which is my testing platform anyways) without any problems.

There is just one question left for me: why do these image properties make such a difference? In my naive mind, "Database - Glorp, DB2 CLI" uses DB2 CLI functionality anyways, so "Database - DB2 CLI" should be a subset of it...? Why does it hurt to load both into a passive Image? Is this some failed double-initialization of Pools? BTW: not all 5 errors seemed to be related to Glorp. One had an empty Set of poolNames. But all 5 errors were gone when I did the change described here...

Anyways, my packaging process is okay now. The issue is solved.

Thanks Mariano for reading and helping, let me know if you need Stack Traces of the packaging or such to research this if it sounds like something worth looking into.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 08:43:28 UTC+2:

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

seems I spoke to soon...

The Error messages still show up in a packaging image on Linux, but not on Windows. When the "Output Image" step is about 60.70% done.

I also tried with a cloned Library and checked multiple times that the passive image properties are the same on Windows and Linux. Cross-Packaging a Headless Linux-Runtime-image on Windows works without any warnings or problems, but doing the same thing on Linux gives me these 5 Errors about invalid array of input buffers. Both on the original library as well as on the cloned one.

I am using emsrv shipped with VAST 9.2.2 on Linux to host the Library, The Linux packaging image runs on the same Linux VM as EMSRV (using access through emsrv on 127.0.0.1) while the Windows VM connects to it. So this is definitely not an EMSRV issue nor do I believe in corrupted Library contents. The Windows Image would complain otherwise, wouldn't it?

Everything is 9.2.2, 64 bits.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 09:48:25 UTC+2:

Okay, I think I found the problem....

The passive image on Windows that packaged without errors had different properties than the one in Linux.

While the Windows Image only had "Database - Glorp, DB2 CLI", the Linux one which showed the errors also had "Database - DB2 CLI" loaded. When I created a new passive Image without "Database - DB2 CLI", packaging and dumping a headless runtime image works without the errors.

How did I find out?

I put the breakpoint in the active image as Mariano suggested and saw things like this:

LibraryObjects class>>#loadRecord:using:ifAbsent:
    self=LibraryObjects
    aRecord=#EmRecord: 'some String with NUL bytes in it'

    loader=an ObjectLoader
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
    answer=nil
AbtNlsKernelApp class[UNIX](Class)>>#objectNamed:in:ifAbsent:
    self=AbtNlsKernelApp[UNIX]
    aName='$AbtNlsPoolDirectory$'
    anApp=AbtNlsKernelApp[UNIX]
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
[] in AbtNlsDbg class>>#recordNlsPoolNames:
    self=AbtNlsDbg
    anImage=an EpRomerImage
    poolNames=Set(#AbtOdbcPlatformFunctions )
    app=AbtNlsKernelApp[UNIX]
    names=nil

Which somehow told me I need to take a look at the packeged Image contents and see if I find something interesting. Which I didn't. Which to me sounds logical, since the Packaging Instructions are the same in both teh Windows and the Linux image.
So the idea was to see what else could make a difference between the two images. If I load the same Packaging Instructions and the same Config Maps on both images, there must be something different "below" my code. Since both images access the same Library on the same Linux machine and use the same EMSRV, the only differende is either in my base image(s) or some code shipped by Instantiations - that was my idea. So I took a look at the passive image properties and found the differenve mentioned above.

Now I am happily packaging my headless image on Linux (where automation works much better than on Windows and which is my testing platform anyways) without any problems.

There is just one question left for me: why do these image properties make such a difference? In my naive mind, "Database - Glorp, DB2 CLI" uses DB2 CLI functionality anyways, so "Database - DB2 CLI" should be a subset of it...? Why does it hurt to load both into a passive Image? Is this some failed double-initialization of Pools? BTW: not all 5 errors seemed to be related to Glorp. One had an empty Set of poolNames. But all 5 errors were gone when I did the change described here...

Anyways, my packaging process is okay now. The issue is solved.

Thanks Mariano for reading and helping, let me know if you need Stack Traces of the packaging or such to research this if it sounds like something worth looking into.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 08:43:28 UTC+2:

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/59c55754-854c-4760-b3a1-91fd5dac209en%40googlegroups.com.

Hi Joachim,

That's interesting. Is there any chance to reproduce this with a simple XD packaging instruction that doesn't depend on your maps/apps? That would be a huge help if we can reproduce it here. 

Thanks,

On Fri, Aug 7, 2020 at 9:39 AM Joachim Tuchel <[hidden email]> wrote:

seems I spoke to soon...

The Error messages still show up in a packaging image on Linux, but not on Windows. When the "Output Image" step is about 60.70% done.

I also tried with a cloned Library and checked multiple times that the passive image properties are the same on Windows and Linux. Cross-Packaging a Headless Linux-Runtime-image on Windows works without any warnings or problems, but doing the same thing on Linux gives me these 5 Errors about invalid array of input buffers. Both on the original library as well as on the cloned one.

I am using emsrv shipped with VAST 9.2.2 on Linux to host the Library, The Linux packaging image runs on the same Linux VM as EMSRV (using access through emsrv on 127.0.0.1) while the Windows VM connects to it. So this is definitely not an EMSRV issue nor do I believe in corrupted Library contents. The Windows Image would complain otherwise, wouldn't it?

Everything is 9.2.2, 64 bits.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 09:48:25 UTC+2:

Okay, I think I found the problem....

The passive image on Windows that packaged without errors had different properties than the one in Linux.

While the Windows Image only had "Database - Glorp, DB2 CLI", the Linux one which showed the errors also had "Database - DB2 CLI" loaded. When I created a new passive Image without "Database - DB2 CLI", packaging and dumping a headless runtime image works without the errors.

How did I find out?

I put the breakpoint in the active image as Mariano suggested and saw things like this:

LibraryObjects class>>#loadRecord:using:ifAbsent:
    self=LibraryObjects
    aRecord=#EmRecord: 'some String with NUL bytes in it'

    loader=an ObjectLoader
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
    answer=nil
AbtNlsKernelApp class[UNIX](Class)>>#objectNamed:in:ifAbsent:
    self=AbtNlsKernelApp[UNIX]
    aName='$AbtNlsPoolDirectory$'
    anApp=AbtNlsKernelApp[UNIX]
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
[] in AbtNlsDbg class>>#recordNlsPoolNames:
    self=AbtNlsDbg
    anImage=an EpRomerImage
    poolNames=Set(#AbtOdbcPlatformFunctions )
    app=AbtNlsKernelApp[UNIX]
    names=nil

Which somehow told me I need to take a look at the packeged Image contents and see if I find something interesting. Which I didn't. Which to me sounds logical, since the Packaging Instructions are the same in both teh Windows and the Linux image.
So the idea was to see what else could make a difference between the two images. If I load the same Packaging Instructions and the same Config Maps on both images, there must be something different "below" my code. Since both images access the same Library on the same Linux machine and use the same EMSRV, the only differende is either in my base image(s) or some code shipped by Instantiations - that was my idea. So I took a look at the passive image properties and found the differenve mentioned above.

Now I am happily packaging my headless image on Linux (where automation works much better than on Windows and which is my testing platform anyways) without any problems.

There is just one question left for me: why do these image properties make such a difference? In my naive mind, "Database - Glorp, DB2 CLI" uses DB2 CLI functionality anyways, so "Database - DB2 CLI" should be a subset of it...? Why does it hurt to load both into a passive Image? Is this some failed double-initialization of Pools? BTW: not all 5 errors seemed to be related to Glorp. One had an empty Set of poolNames. But all 5 errors were gone when I did the change described here...

Anyways, my packaging process is okay now. The issue is solved.

Thanks Mariano for reading and helping, let me know if you need Stack Traces of the packaging or such to research this if it sounds like something worth looking into.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 08:43:28 UTC+2:

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/59c55754-854c-4760-b3a1-91fd5dac209en%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Mariano,

I'll try to isolate it. Will probably take a few days...

Joachim

[hidden email] schrieb am Freitag, 7. August 2020 um 16:13:29 UTC+2:

Hi Joachim,

That's interesting. Is there any chance to reproduce this with a simple XD packaging instruction that doesn't depend on your maps/apps? That would be a huge help if we can reproduce it here. 

Thanks,

On Fri, Aug 7, 2020 at 9:39 AM Joachim Tuchel <[hidden email]> wrote:

seems I spoke to soon...

The Error messages still show up in a packaging image on Linux, but not on Windows. When the "Output Image" step is about 60.70% done.

I also tried with a cloned Library and checked multiple times that the passive image properties are the same on Windows and Linux. Cross-Packaging a Headless Linux-Runtime-image on Windows works without any warnings or problems, but doing the same thing on Linux gives me these 5 Errors about invalid array of input buffers. Both on the original library as well as on the cloned one.

I am using emsrv shipped with VAST 9.2.2 on Linux to host the Library, The Linux packaging image runs on the same Linux VM as EMSRV (using access through emsrv on 127.0.0.1) while the Windows VM connects to it. So this is definitely not an EMSRV issue nor do I believe in corrupted Library contents. The Windows Image would complain otherwise, wouldn't it?

Everything is 9.2.2, 64 bits.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 09:48:25 UTC+2:

Okay, I think I found the problem....

The passive image on Windows that packaged without errors had different properties than the one in Linux.

While the Windows Image only had "Database - Glorp, DB2 CLI", the Linux one which showed the errors also had "Database - DB2 CLI" loaded. When I created a new passive Image without "Database - DB2 CLI", packaging and dumping a headless runtime image works without the errors.

How did I find out?

I put the breakpoint in the active image as Mariano suggested and saw things like this:

LibraryObjects class>>#loadRecord:using:ifAbsent:
    self=LibraryObjects
    aRecord=#EmRecord: 'some String with NUL bytes in it'

    loader=an ObjectLoader
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
    answer=nil
AbtNlsKernelApp class[UNIX](Class)>>#objectNamed:in:ifAbsent:
    self=AbtNlsKernelApp[UNIX]
    aName='$AbtNlsPoolDirectory$'
    anApp=AbtNlsKernelApp[UNIX]
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
[] in AbtNlsDbg class>>#recordNlsPoolNames:
    self=AbtNlsDbg
    anImage=an EpRomerImage
    poolNames=Set(#AbtOdbcPlatformFunctions )
    app=AbtNlsKernelApp[UNIX]
    names=nil

Which somehow told me I need to take a look at the packeged Image contents and see if I find something interesting. Which I didn't. Which to me sounds logical, since the Packaging Instructions are the same in both teh Windows and the Linux image.
So the idea was to see what else could make a difference between the two images. If I load the same Packaging Instructions and the same Config Maps on both images, there must be something different "below" my code. Since both images access the same Library on the same Linux machine and use the same EMSRV, the only differende is either in my base image(s) or some code shipped by Instantiations - that was my idea. So I took a look at the passive image properties and found the differenve mentioned above.

Now I am happily packaging my headless image on Linux (where automation works much better than on Windows and which is my testing platform anyways) without any problems.

There is just one question left for me: why do these image properties make such a difference? In my naive mind, "Database - Glorp, DB2 CLI" uses DB2 CLI functionality anyways, so "Database - DB2 CLI" should be a subset of it...? Why does it hurt to load both into a passive Image? Is this some failed double-initialization of Pools? BTW: not all 5 errors seemed to be related to Glorp. One had an empty Set of poolNames. But all 5 errors were gone when I did the change described here...

Anyways, my packaging process is okay now. The issue is solved.

Thanks Mariano for reading and helping, let me know if you need Stack Traces of the packaging or such to research this if it sounds like something worth looking into.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 08:43:28 UTC+2:

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/59c55754-854c-4760-b3a1-91fd5dac209en%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Hi Joachim,

I created a very simple headless GLORP/DB2 application for testing purposes and tried packaging using the following scenarios.  All tests run using 9.2.2 x64:

1) On Windows x64 using  UNIX XD image with Database - Glorp, DB2 CLI and Database - DB2 CLI  installed features.

2) On Windows x64 using  UNIX XD image with only  Database - Glorp, DB2 CLI  installed feature.

3) On Linux x64 using  UNIX XD image with Database - Glorp, DB2 CLI and Database - DB2 CLI  installed features.

4) On Linux x64 using  UNIX XD image with only  Database - Glorp, DB2 CLI  installed feature.

I did not see any of the errors you documented in the Transcript, or elsewhere, for any of the scenarios.

My test app has a single class method which creates a connection to the database and then creates and deletes a table from the Samples database:

runTest

"comment"

| login table accessor keyField |

login := Login new 

database: DB2Platform new; 

username: '<username>';

password: '<password>';

connectString: 'sample'.

accessor := DatabaseAccessor forLogin: login. accessor login.

table := DatabaseTable named: 'GlorpTest'.

keyField := table createFieldNamed: 'cust_no' type: accessor platform int4. 

table addAsPrimaryKeyField: keyField.

table createFieldNamed: 'cust_name' type: (accessor platform varChar: 255).

accessor createTable: table ifError: [:err |].

accessor dropTable: table ifError: [:err |].

accessor logout.

The prereqs for the app are GlorpVAPortCLISupport and GlorpVAPortPostLoad.  Might be interesting to see what results you get with this. Maybe use this as a starting point to develop a better example.

An additional suggestion ... if you do have some defective LibraryObjects, I don't think cloning will eliminate them.  Maybe you should try starting with a brand new manager and export your code into it to see if the problem still exists.

Regards,

Bob

On Friday, August 7, 2020 at 3:16:53 PM UTC-4 [hidden email] wrote:

Mariano,

I'll try to isolate it. Will probably take a few days...

Joachim

[hidden email] schrieb am Freitag, 7. August 2020 um 16:13:29 UTC+2:

Hi Joachim,

That's interesting. Is there any chance to reproduce this with a simple XD packaging instruction that doesn't depend on your maps/apps? That would be a huge help if we can reproduce it here. 

Thanks,

On Fri, Aug 7, 2020 at 9:39 AM Joachim Tuchel <[hidden email]> wrote:

seems I spoke to soon...

The Error messages still show up in a packaging image on Linux, but not on Windows. When the "Output Image" step is about 60.70% done.

I also tried with a cloned Library and checked multiple times that the passive image properties are the same on Windows and Linux. Cross-Packaging a Headless Linux-Runtime-image on Windows works without any warnings or problems, but doing the same thing on Linux gives me these 5 Errors about invalid array of input buffers. Both on the original library as well as on the cloned one.

I am using emsrv shipped with VAST 9.2.2 on Linux to host the Library, The Linux packaging image runs on the same Linux VM as EMSRV (using access through emsrv on 127.0.0.1) while the Windows VM connects to it. So this is definitely not an EMSRV issue nor do I believe in corrupted Library contents. The Windows Image would complain otherwise, wouldn't it?

Everything is 9.2.2, 64 bits.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 09:48:25 UTC+2:

Okay, I think I found the problem....

The passive image on Windows that packaged without errors had different properties than the one in Linux.

While the Windows Image only had "Database - Glorp, DB2 CLI", the Linux one which showed the errors also had "Database - DB2 CLI" loaded. When I created a new passive Image without "Database - DB2 CLI", packaging and dumping a headless runtime image works without the errors.

How did I find out?

I put the breakpoint in the active image as Mariano suggested and saw things like this:

LibraryObjects class>>#loadRecord:using:ifAbsent:
    self=LibraryObjects
    aRecord=#EmRecord: 'some String with NUL bytes in it'

    loader=an ObjectLoader
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
    answer=nil
AbtNlsKernelApp class[UNIX](Class)>>#objectNamed:in:ifAbsent:
    self=AbtNlsKernelApp[UNIX]
    aName='$AbtNlsPoolDirectory$'
    anApp=AbtNlsKernelApp[UNIX]
    aBlock=[] in AbtNlsDbg class>>#recordNlsPoolNames:
[] in AbtNlsDbg class>>#recordNlsPoolNames:
    self=AbtNlsDbg
    anImage=an EpRomerImage
    poolNames=Set(#AbtOdbcPlatformFunctions )
    app=AbtNlsKernelApp[UNIX]
    names=nil

Which somehow told me I need to take a look at the packeged Image contents and see if I find something interesting. Which I didn't. Which to me sounds logical, since the Packaging Instructions are the same in both teh Windows and the Linux image.
So the idea was to see what else could make a difference between the two images. If I load the same Packaging Instructions and the same Config Maps on both images, there must be something different "below" my code. Since both images access the same Library on the same Linux machine and use the same EMSRV, the only differende is either in my base image(s) or some code shipped by Instantiations - that was my idea. So I took a look at the passive image properties and found the differenve mentioned above.

Now I am happily packaging my headless image on Linux (where automation works much better than on Windows and which is my testing platform anyways) without any problems.

There is just one question left for me: why do these image properties make such a difference? In my naive mind, "Database - Glorp, DB2 CLI" uses DB2 CLI functionality anyways, so "Database - DB2 CLI" should be a subset of it...? Why does it hurt to load both into a passive Image? Is this some failed double-initialization of Pools? BTW: not all 5 errors seemed to be related to Glorp. One had an empty Set of poolNames. But all 5 errors were gone when I did the change described here...

Anyways, my packaging process is okay now. The issue is solved.

Thanks Mariano for reading and helping, let me know if you need Stack Traces of the packaging or such to research this if it sounds like something worth looking into.

Joachim

Joachim Tuchel schrieb am Mittwoch, 5. August 2020 um 08:43:28 UTC+2:

what's interesting: when I do the XD Packaging in VA 9.2.2 on Windows (also 64 bits), using the very same library, The errors don't occur in the Transcript... ???

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/59c55754-854c-4760-b3a1-91fd5dac209en%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/