[Glass] callbackMarker not found in Seaside stack

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

There is no difference in the code, same version was loaded

On Mon, May 19, 2014 at 5:47 PM, Dale Henrichs

<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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
>>> <[hidden email]> 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
>>>> <[hidden email]> 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 <[hidden email]>
>>>>> 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
>>>>>> [hidden email]
>>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>
>>>>>
>>>>
>>>
>>
>

> 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 ...

Ok, can see that

> 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 can't tell, will have to dig more

> 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...

Ok, but that is not simple. There's some ajax involved and yes,
funkiness there. It would be nice if I can show you...

> 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

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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

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 <[hidden email]> wrote:

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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

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 <[hidden email]> 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 <[hidden email]> wrote:

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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