[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

Otto,

Could you run the WACallbackTest tests in both data bases? There are test
cases that involve WACallback >> evaluateWithFieldValues in a couple of
different scenarios, so it would be good to know that the tests are passing
...

Dale


On Mon, May 19, 2014 at 7:31 AM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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/191b36c9/attachment-0001.html>