[Glass] callbackMarker not found in Seaside stack
Otto Behrens
otto at finworks.biz
Mon May 19 07:02:51 PDT 2014
Hi,
We have a GemStone database (3.1.0.5) 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
called.
Thanks
Otto & Iwan
More information about the Glass
mailing list