[Glass] callbackMarker not found in Seaside stack

[Dale Henrichs]

On Wed, May 21, 2014 at 1:45 AM, Otto Behrens <otto at finworks.biz> wrote:

> Hi,
>
> Pardon the delay on the response here. We decided to simplify the flow of
> screens here to avoid the problem, in the light of a possibly complex way
> that we're implementing the requirement and a pressing client.
>

That's okay, I put the time to good use:)


> But we'd like to explore this a bit more to see if we can find this
> because it may be a problem elsewhere in our system or for someone else.
>
> Firstly, we are using https://github.com/glassdb/Seaside30. The comment
> says Seaside 3.0.7.1. I don't know how to figure out what version of
> seaside this is besides trusting the comment.
>

Trust the comment. There are later versions of 3.0 on smalltalk hub ...
3.0.9.1 is probably the latest version available that passes tests in
GemStone...


> Looking at logs when loading from scratch does not tell me much. How will
> I go about figuring out the version that we've got loaded?
>

The best way that I know of is to record the SHA of the commit when you do
the load. I have made  extensions to Metacello that record the SHA when you
do the load (part of the registration).

tODE has a `project list` that displays the SHA from the metacello
registration. tODE also "monitors" the local git repo for changes to the
SHA and displays this skew in the `project list` ... from the `project
list` you can access the commit log (which has the SHA of each commit) and
from the commit log you can do diffs between the selected commit and the
image ...

This typs of problem is exactly why I am pushing to get tODE released ...

>From Johan's recent mail, I take it that
> https://github.com/glassdb/Seaside31 could be good to upgrade to.
>

> To get back to the problem, I think the continuation was created with
>
> Scriptaculous >> lightbox: aComponent
> ^ self wait: [ :cc |
> self
>  show: aComponent
> onAnswer: cc
> delegation: (SULightbox new
>  delegate: aComponent;
> yourself).
> WARenderNotification signal ]
>
> Yes, we still have some Scriptaculous bits to get rid of, so if this is
> the problem, the time is now.
>
> What do you think? Is this it?
>

The way to tell is to monitor the stack as the calls are being made to
evaluateWithArgument:...you can automate things by using the object log to
record the source/class/lineno of the callback block and the location of
the evaluateWithArgument: call ... when you hit the error, peek at the last
entry in the object log.

When I'm doing this kind of work, I nuke the object log before each test
run so I have fewer entries to look at ...

>
> Thanks
> Otto
>
>
> On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Otto,
>>
>> Another possibility ... although I don't know if this kind of thing would
>> be possible but here goes nothing ...
>>
>> If the callback that we're looking at with the broken stack was created
>> during WADispatchCallback>>evaluateWithArgument: or
>> WAMultiSelectTag>>triggerCallback and inform: answer was run in
>> WACallbackRegistry>>handle:, then the call back would have been created
>> with one less frame on the stack (no do: frame) ...  and that would provide
>> us with a nice off by one error ...
>>
>> some logging in the methods WADispatchCallback>>evaluateWithArgument: and
>> WAMultiSelectTag>>triggerCallback, where you record the oop of
>> theWACallback instance  and  logging in WACallbackRegistry>>handle:
>> recording the oops of WACallbacks run should rule this hare-brained idea
>> out or rule it right into play:) ...
>>
>> Dale
>>
>>
>> On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>> Otto,
>>>
>>> I haven't been able to reproduce the bad error yet and I think that the
>>> corruption is being caused by the previous callback in the set ... the
>>> stack is corrupt at the point you try to create the continuation for the
>>> inform: in the validation block ...
>>>
>>> setting breakpoints in the WACallback>>evaluateWithFieldValues: will
>>> catch the first callback in this sequence .. check to see if the stack
>>> looks corrupt in the first call, then continue and see if the stack looks
>>> corrupt before executing the code for the second callback ... if we can
>>> isolate the transition from good stack to bad stack, we'll be on our way to
>>> a solution...
>>>
>>> I'm a bit suspicious of Magritte in the mix and the#reset message ... if
>>> the structure of objects have been changed between the time the
>>> continuation is created and the time it gets used, there might be trouble
>>> ... but I'm only grasping at straws at this point in time ... BTW, what
>>> version of Seaside and Magritte are you using?
>>>
>>> If Pieter's case is simpler, we might be able to figure it out easier
>>> ... I'd like to see the two addForm: methods:) Just in case something jumps
>>> out at me...
>>>
>>> Dale
>>>
>>>
>>>
>>>
>>> On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>>> Otto,
>>>>
>>>> Given an instance of WACallback, you can determine the source code of
>>>> the method where the callback is defined by looking at the `block` instance
>>>> variable og a WACallBack instance ... then in 3.1:
>>>>
>>>>   block _method sourceString.              "source"
>>>>   block _method inClass                        "class"
>>>>   block _method _lineDeltaForBlock    "line number in source (ignoring
>>>> selector)"
>>>>
>>>> This can be done from a debugger (topaz) when error occurs ... navigate
>>>> up the stack to the WACallback>>evaluateWithFieldValues: frame... get the
>>>> oop of the _method (use `display oops`) and then sued the `send` command to
>>>> send the three different messages:
>>>>
>>>>   send @34379893 sourceString
>>>>
>>>> ... still digging ...
>>>>
>>>> Dale
>>>>
>>>>
>>>>
>>>> On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <otto at finworks.biz>wrote:
>>>>
>>>>> Thank you, Dale. I'm finally at home :)
>>>>>
>>>>>
>>>>> On Monday, May 19, 2014, Dale Henrichs <
>>>>> dale.henrichs at gemtalksystems.com> wrote:
>>>>>
>>>>>> Otto,
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> I'm finally in the office ) and will spend some time today getting
>>>>>> myself grounded in continuations again ... then I should have a better idea
>>>>>> how to proceed ...
>>>>>>
>>>>>> Dale
>>>>>>
>>>>>>
>>>>>> On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <otto at finworks.biz>wrote:
>>>>>>
>>>>>>> > perhaps capturing the stack at the point the continue is created
>>>>>>> will give
>>>>>>> > us clues ...
>>>>>>>
>>>>>>> Attached are some stacks that I hacked in by calling the following
>>>>>>> method where we create them:
>>>>>>>
>>>>>>> WAPartialContinuation >> printStack
>>>>>>> | stream |
>>>>>>> stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop
>>>>>>> printString.
>>>>>>> [ stream nextPutAll: partial printString ] ensure: [ stream close ]
>>>>>>>
>>>>>>> It does not tell me much at the moment. But perhaps you can see
>>>>>>> something. Or perhaps you have a better printing method that I can
>>>>>>> call?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Otto
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140521/7e1167d0/attachment-0001.html>