[Glass] callbackMarker not found in Seaside stack

[Otto Behrens]

both runs fine it seems:

run
WACallbackTest suite run printString
%
12 run, 12 passes, 0 expected defects, 0 failures, 0 errors, 0 unexpected passes



On Mon, May 19, 2014 at 4:56 PM, Dale Henrichs
<dale.henrichs at gemtalksystems.com> wrote:
> 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
>>
>>
>