[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

Which code is for the working case and which code si for the broken case
... do they differ greatly?

Dale


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

> 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/9ca20211/attachment.html>