[Glass] Internal error performing an external command from the service vm

Hi Dale,

I notice those in the release notes for 3.1.0.5 but not in the 3.1.0.6 ?

I guess one needs to run through an image upgrade?

thanks

Johan

On 02 Mar 2015, at 19:11, Dale Henrichs via Glass <[hidden email]> wrote:

Johan,

This particular problem looks like a bug in process scheduling ... there were a number of fixes to process scheduling in this area for 3.1.0.6 so the bug is likely fixed there ...

Dale

On 03/02/2015 08:10 AM, Johan Brichau via Glass wrote:

Hi,

I’m getting an error in GS 3.1.0.5 where a seaside service vm is throwing a c-level stack (attached) at me following this error:

UTL_GUARANTEE failed, File /export/jupiter3/users/buildgss/gs64/3101/build31878/src/intloopsup.c line 9183	

This happens when I launch an external command (using #performOnServer: ) that is quite resource intensive (long, a lot of memory).
I can trigger it frequently but not consistently. It might have to do with the machine running out of resources, but I thought I would ask the question here.

cheers
Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On 02 Mar 2015, at 21:13, James Foster <[hidden email]> wrote:

I notice those in the release notes for 3.1.0.5 but not in the 3.1.0.6 ?

I guess one needs to run through an image upgrade?

Yes, absolutely. Replacing the binaries is only part of the upgrade. If you do not update the image, then you are not only missing some of the fixes but you are actually in a dangerous situation. Primitives may have changed and the old methods could be calling the wrong primitives. Every upgrade requires an image upgrade as well as an executable upgrade.

What is the last line in DbfHistory?

On 02 Mar 2015, at 21:13, James Foster <[hidden email]> wrote:

I notice those in the release notes for 3.1.0.5 but not in the 3.1.0.6 ?

I guess one needs to run through an image upgrade?

Yes, absolutely. Replacing the binaries is only part of the upgrade. If you do not update the image, then you are not only missing some of the fixes but you are actually in a dangerous situation. Primitives may have changed and the old methods could be calling the wrong primitives. Every upgrade requires an image upgrade as well as an executable upgrade.

I guess I was just a little lazy asking the question wether it was just an executable upgrade from 3.1.0.5 to 3.1.0.6.

Understood. I will not ask such a silly question again :)

What is the last line in DbfHistory?

Do you mean (UserGlobals at: #DbfHistory) ?

It says:

GemStone/S64 v3.1.0.2 kernel classes filein completed at 28/11/2012 16:39:48

upgrade to GemStone/S 64 Bit 3.1.0.5 completed at 12/01/2014 11:19:32

cheers

Johan