[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

Hmmm,

Is the input data identical as well?


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

> There is no difference in the code, same version was loaded
>
> On Mon, May 19, 2014 at 5:47 PM, Dale Henrichs
> <dale.henrichs at gemtalksystems.com> wrote:
> > 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/a8967db8/attachment-0001.html>