[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

Otto,

In the broken case, it appears that you _are_ in the do loop that calls
evaluateWithFieldValues: (frame 66). The corresponding frame in the working
case is frame 54 ...

It looks like the index of do loop is 2, so that implies that the either a)
the first callback was "corrupt" or b) the second callback was created
incorrectly ...

I would like to be able to see what the stack looked like when the second
callback was created ... Looking at the method source for the methods
involved in rendering the component would be a good place to start, since
there is likely something funky there...

Dale


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

> I attach the full working and broken stacks.
>
> I also cut some stuff out and commented in both (the _snipped_ versions).
>
> On Mon, May 19, 2014 at 4:31 PM, 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/8e466489/attachment.html>