[Glass] callbackMarker not found in Seaside stack

Otto Behrens otto at finworks.biz
Mon May 19 07:02:51 PDT 2014


We have a GemStone database ( that apparently misbehaves in
seaside callback processing. Has anyone encountered something like
this? We'll appreciate the help we can get.

We are processing callbacks as the following method is on the stack:

WACallbackRegistry >> handle: aRequestContext

The method calls evaluateWithFieldValues: on each callback:
set sorted do: [ :callback | callback evaluateWithFieldValues: (fields
allAt: callback key) ]

In a database that behaves, the previous stack frame (n - 1) is

WACallback >> evaluateWithFieldValues:

and the one prior to that is:

GSNMethod class >> _noopReturnTos

The subequent stack list appears fine, evaluating the callback block, etc.

In another database that breaks,

WACallback >> evaluateWithFieldValues:

is not on the stack. WACallbackRegistry >> handle: is directly
preceded by GSNMethod class >> _noopReturnTos. This causes the method

GRGemStonePlatform >> callbackMarker

which searches for the WACallback frame on the stack to return nil,
which means that call: or answer: breaks with 'You can only #call: and
#answer: from within a callback or a Task.'. We are in a callback
phase and we know that WACallback >> evaluateWithFieldValues: is
called, but somehow it is not on the stack.

It may be a compiler optimisation or something like that. In that
case, the algorithm in #callbackMarker cannot reliably work, unless
there's a way to force a class or method to be on the stack if it is

Otto & Iwan

More information about the Glass mailing list