[Glass] callbackMarker not found in Seaside stack

[Otto Behrens]

I know the stack I'm working on better, so easier for me to give you bits
on this one. Here's what you may be interested in:

Investment >> matchComponent: aComponent
[
self isMatched
ifFalse: [
aComponent
call:
(MatchInvestmentPage new
instruction: self;
yourself).
self addBuysForEditing.
aComponent reset ] ]
on: ValidateError
do: [ :err |
aComponent inform: err messageText.
aComponent answer ]

This is where the callback block is.

 FinePrintFormDecoration >> printButton: each on: html
| label |
label := self labelForSelector: each key.
^ html submitButton
accessKey: label first;
style: self buttonStyle;
value: (self component labelForSelector: each key);
callback: [ self performAction: each key selector: each value asSymbol ];
text: label;
yourself

and this horrible method is performed in the callback block:

matchBankEntryCallbackForComponent: aComponent
| selectedPaymentMethod |
selectedPaymentMethod := (aComponent childAt: aComponent memento model
descriptionPaymentMethod) component memento
cache at: self bankTransfer descriptionPaymentMethod.
(self isNew and: [ self bankTransfer isDebitOrderAccountVisibleForType:
selectedPaymentMethod ])
ifTrue: [ aComponent showMessage: 'Cannot match an investment with this
method of payment' ]
ifFalse: [ self saveComponent: aComponent ifValidDo: [ self matchComponent:
aComponent ] ]




On Mon, May 19, 2014 at 5:24 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Otto,
>
> In Pieter's example, I would be interested to see the source code to the
> addFrom: messages .. presumably there is a difference between the two
> methods ... and at this point in time the differences are interesting ...
>
> Dale
>
>
> On Mon, May 19, 2014 at 7:56 AM, 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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140519/97ece18d/attachment-0001.html>