[Glass] Error 2252 and Topaz

[Dale Henrichs via Glass]

On 12/04/2016 12:35 PM, BrunoBB via Glass wrote:
> Hi All,
>
> First the Descritpion (then the question):
> I just fix an error in my web app that it took me an hour to find.
>
> The web run on a Jade session and after a click in the web app --> the gem
> loop crash with the: "Error #2252" (try to find that number in gemstone64
> manuals but no luck).
I'm surprised that you are just getting an "Error #2252" ... where is 
that error coming from ... usually GemStone errors are generated with a 
bit more information. If you send the message #description to an 
exception you should get a good error message.
>
> In GS32 it has something to do with stack (#rtErrLoadSaveStack):
> "Error encountered while saving or reloading Smalltalk DB execution state.
> Execution cannot continue."
> Do not now if it is the same in GS64.

In 64 bit you can do the following things to try to understand the error 
number.

Look up the key for the error number in ErrorSymbols

   ErrorSymbols keyAtValue: 2252

gives you symbol #'rtErrLoadSaveStack' and you can do senders of that 
symbol to see if and where the error is signalled in the Smalltalk code 
... in this case there are none, but the symbol itself 
#'rtErrLoadSaveStack' is meaningful ... to us:)

Finally , looking the error number up in the LegacyErrNumMap:

   LegacyErrNumMap at: 2252

which again does not give you much more information.
>
> Anyway the log files did show nothing and i could not run Topaz (to
> replicate this with a Topaz session). Running "topaz" did not start topaz it
> just show: "command not found". Even with "find / -name topaz" and executing
> those files the same answer "command not found"
In GsDevKit_home, you should use the startTopaz command to launch topaz 
for a particular stone:

   $GS_HOME/bin/startTopaz <stone-name> <topaz arguments>

The startTopaz command sets up the GemStone env variables and arranges 
to use a .topazini that is sufficient for starting a linked topaz (using 
the -l topaz option)
>
> The error was bug in my app i forgot to add "^" in a method. (fixed now :)
>
> Questions:
> * Why i did not get a wallback or anything in the logs ?
>     + Instead of receiving aString the method was receiving aSeaside
> component. It should be a normal #doesNotUnderstand: situation ?
> * And how to execute Topaz ?
These are good questions ... the #'rtErrLoadSaveStack' is a pretty deep 
error in the vm and there are quite a few different conditions that can 
lead to this error. The error #description should contain a bit of 
information about what conditions caused the error. Most if not all of 
the standard Seaside error handlers use should be attempting to dump a 
stack with the error description as well as snap off an error 
continuation to the Object log ... Are you using a standard seaside 
server script?

I am surprised that you are getting an error message that looks like 
"Error #2252" - I've searched through the Seaside code base and not 
found an error message that is generated like this, so I am curious how 
that error message is being generated. Could you provide the gem log 
itself so that we can see if there is any additional information in the 
log ... we're also curious what version of GemStone you are using.

We're guessing that you are getting the #'rtErrLoadSaveStack' because of 
recursion and or trying to install a partial continuation (used by 
Seaside) when there is not enough room on the stack ... as I mentioned 
there are a several other possibilities for this error and trying to 
understand why you are not getting good information is a good thing to 
understand ... the error handling in Seaside might need a bit more 
bullet proofing ...

Dale