[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

Otto,

While I refresh my continuation skilz:), could you send me some stacks
(don't need args)?

I'd like to see the full stack for the good callback and the full stack for
the bad callback ... I'm also interested in the seaside methods where the
callbacks are being created ... method source and an example call stack for
the method would help ...

We're creating partial continuations, so it's probable that the bug is
introduced a callback creation time, so a picture of the stack at that time
will be useful .. at the end of the day, I will probably need to be able to
reproduce the problem so that I can get my hands on it in a c debugger...

Dale


On Mon, May 19, 2014 at 7:02 AM, Otto Behrens <otto at finworks.biz> wrote:

> 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
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140519/48c60e7d/attachment.html>