Smalltalk › Gemtalk › GLASS

[GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

Mariano Martinez Peck

[GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.

self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

Johan Brichau-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

hey Mariano,

Which versions of gemstone and seaside are you running?

Johan

On 09 Jun 2014, at 22:51, Mariano Martinez Peck <[hidden email]> wrote:

> Hi guys,
>
> I have a working code in Pharo but in GemStone I get an error:
>
> a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.
>
> I have a WATask subclass where at certain point I do:
>
> comp := MyComponent new.
> self call: comp
>
> That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.
>
> I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.
>
> Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...
>
> Anyway....any ideas of what the problem could be?
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com

Mariano Martinez Peck

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

Seaside 3.0.9 and GemStone 3.1.0.4.

Was this already reported and fixed?

On Mon, Jun 9, 2014 at 5:52 PM, Johan Brichau <[hidden email]> wrote:

hey Mariano,

Which versions of gemstone and seaside are you running?

Johan

On 09 Jun 2014, at 22:51, Mariano Martinez Peck <[hidden email]> wrote:

> Hi guys,
>
> I have a working code in Pharo but in GemStone I get an error:
>
> a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.
>
> I have a WATask subclass where at certain point I do:
>
> comp := MyComponent new.
> self call: comp
>
> That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.
>
> I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.
>
> Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...
>
> Anyway....any ideas of what the problem could be?
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Mariano Martinez Peck

Mariano,

IIRC, in Otto's case we discovered that had some "oddly" constructed blocks on the stack ... a close reading of the stack showed that when the continuation was reified on the stack, a frame (the one with the WATask method) was missing ...

Otto resolved the problem by rewriting his method a bit[1] ... so there is a bug out there, but we have not been able to get a sample into the lab, where we can dissect it and come up with a solution ...

In the sequence of three messages starting here[2], I describe some things to do and some suspicions of mine based on studying Otto's stack ...

a stack would help me determine if your bug is in the same ballpark as Otto's...

Dale

[1] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759814.html

[2] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759613.html

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

Mariano Martinez Peck

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

Dale, how can I share with you a "stack" ?

Thanks,

On Mon, Jun 9, 2014 at 7:48 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,
IIRC, in Otto's case we discovered that had some "oddly" constructed blocks on the stack ... a close reading of the stack showed that when the continuation was reified on the stack, a frame (the one with the WATask method) was missing ...

Otto resolved the problem by rewriting his method a bit[1] ... so there is a bug out there, but we have not been able to get a sample into the lab, where we can dissect it and come up with a solution ...

In the sequence of three messages starting here[2], I describe some things to do and some suspicions of mine based on studying Otto's stack ...

a stack would help me determine if your bug is in the same ballpark as Otto's...

Dale

[1] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759814.html

[2] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759613.html

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

Larry Kellogg

[GS/SS Beta] Problem running GemTools

So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.

However, I backed up my repository today, and deleted old tran logs.

When I tried to run gemtools.sh, I could not get the launcher to come up.

First, I get this silly error

$ sh gemtools.sh

$ Could not open display `(null)'.

and when I do this:

export DISPLAY=mylocalipaddress:0

Squeak comes up running the Pharo image but no windows display on my local machine. 

I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work? 

Larry

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Mariano Martinez Peck

Mariano,

If you have a GemTools debugger up on the continuation, there is a `copy stack` menu item that brings up an Information Required and the stack can be copied from that ... if a continuation was not created then you should find a stack in the gem log file ... there might be a stack in the gem log file no matter what ...

Dale

On Mon, Jun 9, 2014 at 4:24 PM, Mariano Martinez Peck <[hidden email]> wrote:

Dale, how can I share with you a "stack" ?

Thanks,

On Mon, Jun 9, 2014 at 7:48 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,
IIRC, in Otto's case we discovered that had some "oddly" constructed blocks on the stack ... a close reading of the stack showed that when the continuation was reified on the stack, a frame (the one with the WATask method) was missing ...

Otto resolved the problem by rewriting his method a bit[1] ... so there is a bug out there, but we have not been able to get a sample into the lab, where we can dissect it and come up with a solution ...

In the sequence of three messages starting here[2], I describe some things to do and some suspicions of mine based on studying Otto's stack ...

a stack would help me determine if your bug is in the same ballpark as Otto's...

Dale

[1] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759814.html

[2] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759613.html

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

Dale Henrichs-3

Re: [GS/SS Beta] Problem running GemTools

In reply to this post by Larry Kellogg

Larry,

I love it that GemStone keeps chugging away:)

It does sound like you need to get X running first ... I upgraded my mac to mavericks a while back, but I don't remember if I had to explicitly get X or not ... seems that I did ...

Dale

On Mon, Jun 9, 2014 at 5:05 PM, Lawrence Kellogg <[hidden email]> wrote:

So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.

However, I backed up my repository today, and deleted old tran logs.

When I tried to run gemtools.sh, I could not get the launcher to come up.

First, I get this silly error

$ sh gemtools.sh
$ Could not open display `(null)'.

and when I do this:

export DISPLAY=mylocalipaddress:0

Squeak comes up running the Pharo image but no windows display on my local machine.

I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work?

Larry

Larry Kellogg

Re: [GS/SS Beta] Problem running GemTools

On Jun 9, 2014, at 8:20 PM, Dale Henrichs <[hidden email]> wrote:

Larry,

I love it that GemStone keeps chugging away:)

Dale,

Oh, it’s amazing, Gemstone just keeps running, week after week, month after month, and I use it ever day. I never managed to find the time to upgrade my repository, so I’m back on 2.4.4.1, IIRC. Still, www.practicemusic.com has been stable for me. I’m bummed that I never figured out how to make any money for all of the hundreds of hours I spent building the site and the iPhone app.

I would be a happy camper if I could convince another company to let me build a system using Gemstone and Seaside. I think the new licensing terms are amazing and should not be an impediment to adopting the technology, if I read the pricing correctly. Sigh. Why are so many bad tools used instead?

It does sound like you need to get X running first ... I upgraded my mac to mavericks a while back, but I don't remember if I had to explicitly get X or not ... seems that I did ...

It appears that X11 is no longer included in OS X! http://support.apple.com/kb/ht5293 Whose ideas was that?

I got gem tools to work by installing XQuartz. Whew. Thanks for the help.

Best,

Larry

Dale

On Mon, Jun 9, 2014 at 5:05 PM, Lawrence Kellogg <[hidden email]> wrote:

So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.

However, I backed up my repository today, and deleted old tran logs.

When I tried to run gemtools.sh, I could not get the launcher to come up.

First, I get this silly error

$ sh gemtools.sh
$ Could not open display `(null)'.

and when I do this:

export DISPLAY=mylocalipaddress:0

Squeak comes up running the Pharo image but no windows display on my local machine.

I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work?

Larry

Richard Sargent

Re: [GS/SS Beta] Problem running GemTools

Administrator

>> Why are so many bad tools used instead?

Flies.

After all, 50,000,000 flies can't be wrong!

On Mon, Jun 9, 2014 at 5:37 PM, Lawrence Kellogg <[hidden email]> wrote:

On Jun 9, 2014, at 8:20 PM, Dale Henrichs <[hidden email]> wrote:

Larry,

I love it that GemStone keeps chugging away:)

Dale,
Oh, it’s amazing, Gemstone just keeps running, week after week, month after month, and I use it ever day. I never managed to find the time to upgrade my repository, so I’m back on 2.4.4.1, IIRC. Still, www.practicemusic.com has been stable for me. I’m bummed that I never figured out how to make any money for all of the hundreds of hours I spent building the site and the iPhone app.

I would be a happy camper if I could convince another company to let me build a system using Gemstone and Seaside. I think the new licensing terms are amazing and should not be an impediment to adopting the technology, if I read the pricing correctly. Sigh. Why are so many bad tools used instead?

It does sound like you need to get X running first ... I upgraded my mac to mavericks a while back, but I don't remember if I had to explicitly get X or not ... seems that I did ...

It appears that X11 is no longer included in OS X! http://support.apple.com/kb/ht5293 Whose ideas was that?

I got gem tools to work by installing XQuartz. Whew. Thanks for the help.

Best,

Larry

Dale

On Mon, Jun 9, 2014 at 5:05 PM, Lawrence Kellogg <[hidden email]> wrote:

So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.

However, I backed up my repository today, and deleted old tran logs.

When I tried to run gemtools.sh, I could not get the launcher to come up.

First, I get this silly error

$ sh gemtools.sh
$ Could not open display `(null)'.

and when I do this:

export DISPLAY=mylocalipaddress:0

Squeak comes up running the Pharo image but no windows display on my local machine.

I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work?

Larry

Larry Kellogg

Re: [GS/SS Beta] Problem running GemTools

On Jun 9, 2014, at 9:41 PM, Richard Sargent <[hidden email]> wrote:

>> Why are so many bad tools used instead?

Flies.

After all, 50,000,000 flies can't be wrong!

Do you mean files?

I hate files.

Larry

On Mon, Jun 9, 2014 at 5:37 PM, Lawrence Kellogg <[hidden email]> wrote:

On Jun 9, 2014, at 8:20 PM, Dale Henrichs <[hidden email]> wrote:

Larry,

I love it that GemStone keeps chugging away:)

Dale,
Oh, it’s amazing, Gemstone just keeps running, week after week, month after month, and I use it ever day. I never managed to find the time to upgrade my repository, so I’m back on 2.4.4.1, IIRC. Still, www.practicemusic.com has been stable for me. I’m bummed that I never figured out how to make any money for all of the hundreds of hours I spent building the site and the iPhone app.

I would be a happy camper if I could convince another company to let me build a system using Gemstone and Seaside. I think the new licensing terms are amazing and should not be an impediment to adopting the technology, if I read the pricing correctly. Sigh. Why are so many bad tools used instead?

It does sound like you need to get X running first ... I upgraded my mac to mavericks a while back, but I don't remember if I had to explicitly get X or not ... seems that I did ...

It appears that X11 is no longer included in OS X! http://support.apple.com/kb/ht5293 Whose ideas was that?

I got gem tools to work by installing XQuartz. Whew. Thanks for the help.

Best,

Larry

Dale

On Mon, Jun 9, 2014 at 5:05 PM, Lawrence Kellogg <[hidden email]> wrote:

So, it has been a long, long time since I have logged onto my Amazon instance to check on my Gemstone instance. The good news is that my application is stable and running without intervention.

However, I backed up my repository today, and deleted old tran logs.

When I tried to run gemtools.sh, I could not get the launcher to come up.

First, I get this silly error

$ sh gemtools.sh
$ Could not open display `(null)'.

and when I do this:

export DISPLAY=mylocalipaddress:0

Squeak comes up running the Pharo image but no windows display on my local machine.

I recently upgraded to Mavericks. Do I have to do something to get the X11 host support to work?

Larry

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Mariano Martinez Peck

Mariano,

From within a component itself it looks like the "standard pattern" is put a `self call:` inside a wait: block like the following:

chooseFrom: aCollection

"Choose an item from the given aCollection. Answer the selected item."

^ self wait: [ :cc | self chooseFrom: aCollection onAnswer: cc ]

The wait: wraps the call: in a seasideSuspendFlowDo: which implements the partial continuation mechanism, so I'd guess that GemStone is getting confused by that ...

I'm trying to remember if nested continuations are "supposed to work" or not ... I seem to remember some old test code that tested for this a regularly blew up ... don't recall if this was the exact case or not ...

Have you tried wrapping with a wait: already?

Dale

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

Mariano Martinez Peck

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

On Tue, Jun 10, 2014 at 11:50 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

From within a component itself it looks like the "standard pattern" is put a `self call:` inside a wait: block like the following:

mmm this is the first time ever I would need to deal with #wait: ...

chooseFrom: aCollection

"Choose an item from the given aCollection. Answer the selected item."

^ self wait: [ :cc | self chooseFrom: aCollection onAnswer: cc ]

The wait: wraps the call: in a seasideSuspendFlowDo: which implements the partial continuation mechanism, so I'd guess that GemStone is getting confused by that ...

Dale, I am confused.

WAComponent >> #call: aComponent

"Pass control from the receiver to aComponent. The receiver will be temporarily replaced with aComponent. Code can return from here later on by sending #answer: to aComponent."

^ self wait: [ :cc | self call: aComponent onAnswer: cc ]

So the #call: already wraps the stuff in a #wait: so why would I need to wrap the #call: send with another #wait: ?

Thanks...I need to get this working in gemstone :(

I'm trying to remember if nested continuations are "supposed to work" or not ... I seem to remember some old test code that tested for this a regularly blew up ... don't recall if this was the exact case or not ...

Have you tried wrapping with a wait: already?

Dale

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

I'm going blind --- the #call;OnAnswer: is wrapped not the call:)... Never mInd..

On Wed, Jun 11, 2014 at 9:40 AM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Jun 10, 2014 at 11:50 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

From within a component itself it looks like the "standard pattern" is put a `self call:` inside a wait: block like the following:

mmm this is the first time ever I would need to deal with #wait: ...

chooseFrom: aCollection

"Choose an item from the given aCollection. Answer the selected item."

^ self wait: [ :cc | self chooseFrom: aCollection onAnswer: cc ]

The wait: wraps the call: in a seasideSuspendFlowDo: which implements the partial continuation mechanism, so I'd guess that GemStone is getting confused by that ...

Dale, I am confused.

WAComponent >> #call: aComponent
"Pass control from the receiver to aComponent. The receiver will be temporarily replaced with aComponent. Code can return from here later on by sending #answer: to aComponent."

^ self wait: [ :cc | self call: aComponent onAnswer: cc ]

So the #call: already wraps the stuff in a #wait: so why would I need to wrap the #call: send with another #wait: ?

Thanks...I need to get this working in gemstone :(

I'm trying to remember if nested continuations are "supposed to work" or not ... I seem to remember some old test code that tested for this a regularly blew up ... don't recall if this was the exact case or not ...

Have you tried wrapping with a wait: already?

Dale

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Mariano Martinez Peck

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Okay, now that I'm focussing on this problem:) The fact that you have two unique instances of #visitTask: _is_ diagnostic....

Is it possible that the method was recompiled at some point in time?

Hmm, in my image when I inspect the visitTask: method I get this:

. -> aGsNMethod

(class)@ -> GsNMethod

(oop)@ -> 231635201

(invariant)@ -> true

debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561

inClass@ -> WATaskVisitor

selector@ -> 22092384

1@ -> 11648

2@ -> 105544526464784

3@ -> 12958305600

4@ -> 132192

5@ -> 55834642352

6@ -> WAPainterVisitor

7@ -> 132208

8@ -> 60129544128

9@ -> 84632912

10@ -> 26306545120

11@ -> 1553472491356928

12@ -> 60129675200

13@ -> 9264

14@ -> 12885099953

15@ -> #'WARenderNotification'->WARenderNotification

16@ -> anExecBlock

17@ -> anExecBlock

18@ -> 22092386

19@ -> 22092128

20@ -> 261120

... and it is size 20. so I think I'd like to see the values of the fields in both of the methods that you are seeing ...

In the mean time, I will start working on getting a "normal continuation" under the inspector and then see if I can trivially reproduce your problem ...

Dale

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

Before I go too far, I'm curious if this is related to the problem that you've discussed on the Seaside list? In that thread I recall that you claimed the problem existed in both Pharo and GemStone ... if that is true then it isn't a unique problem to GemStone and not a bug per se...

Dale

On Wed, Jun 11, 2014 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Okay, now that I'm focussing on this problem:) The fact that you have two unique instances of #visitTask: _is_ diagnostic....

Is it possible that the method was recompiled at some point in time?

Hmm, in my image when I inspect the visitTask: method I get this:

. -> aGsNMethod

(class)@ -> GsNMethod
(oop)@ -> 231635201
(invariant)@ -> true
debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561
inClass@ -> WATaskVisitor
selector@ -> 22092384
1@ -> 11648

2@ -> 105544526464784
3@ -> 12958305600
4@ -> 132192
5@ -> 55834642352

6@ -> WAPainterVisitor
7@ -> 132208
8@ -> 60129544128
9@ -> 84632912

10@ -> 26306545120
11@ -> 1553472491356928
12@ -> 60129675200
13@ -> 9264

14@ -> 12885099953
15@ -> #'WARenderNotification'->WARenderNotification
16@ -> anExecBlock

17@ -> anExecBlock
18@ -> 22092386
19@ -> 22092128
20@ -> 261120

... and it is size 20. so I think I'd like to see the values of the fields in both of the methods that you are seeing ...

In the mean time, I will start working on getting a "normal continuation" under the inspector and then see if I can trivially reproduce your problem ...

Dale

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Dale Henrichs-3

Regarding the different sizes. The compiled method itself shows up as size 20 (as in previous mail) and here's the method context from a live stack (of size 29 ... note that the oops are the same):

--------------------

. -> aGsNMethod

.. -> WATaskVisitor>>visitTask: @5 line 5

(class)@ -> GsNMethod

(oop)@ -> 231635201

debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561

inClass@ -> WATaskVisitor

selector@ -> 22092384

1@ -> 11648

2@ -> 105544526464784

3@ -> 12958305600

4@ -> 132192

5@ -> 55834642352

6@ -> WAPainterVisitor

7@ -> 132208

8@ -> 60129544128

9@ -> 84632912

10@ -> 26306545120

11@ -> 1553472491356928

12@ -> 60129675200

13@ -> 9264

14@ -> 12885099953

15@ -> #'WARenderNotification'->WARenderNotification

16@ -> anExecBlock

17@ -> anExecBlock1

18@ -> nil

19@ -> aGsNativeCode

20@ -> 0

21@ -> 22092386

22@ -> WATaskErrorFunctionalTest

23@ -> aGsNativeCode

24@ -> 0

25@ -> 22092128

26@ -> ExecBlock

27@ -> aGsNativeCode

28@ -> 0

29@ -> 261120

and here's the block context from within the visitTask: method (of size 8):

[] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4aGsNMethod/

--------------------

. -> aGsNMethod

.. -> [] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4

(class)@ -> GsNMethod

(oop)@ -> 250091265

debugInfo@ -> anArray( 805306624, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotification...

iFields1@ -> 15762598695796992

inClass@ -> aGsNMethod

selector@ -> 29216

1@ -> 14568529071472

2@ -> 1610483264

3@ -> 8589936576

4@ -> 131744

5@ -> WATaskErrorFunctionalTest

6@ -> aGsNativeCode

7@ -> 0

8@ -> 1825664

The oop in this case is the oop of the "block"...

So in looking at your stack trace only the visitTask: block is on the stack and the visitTask: method itself is not on the stack ... so that is why you are getting the error ...

To get this info, I am simply running the WATaskErrorFunctional test and in this case both the block and the method are on the stack ...

Soooooo, if you could provide me with the code for a component that reproduces the problem, I'll be able to make progress on finding a solution ...

I will make a couple of stabs at trying to build such a component, but you are much closer to the real problem than I am ... I'm guessing that the problem is somehow related to details of the block structure on the stack, since Otto was able to reformulate his method to make the problem "go away" ...

Dale

On Wed, Jun 11, 2014 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Okay, now that I'm focussing on this problem:) The fact that you have two unique instances of #visitTask: _is_ diagnostic....

Is it possible that the method was recompiled at some point in time?

Hmm, in my image when I inspect the visitTask: method I get this:

. -> aGsNMethod

(class)@ -> GsNMethod
(oop)@ -> 231635201
(invariant)@ -> true
debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561
inClass@ -> WATaskVisitor
selector@ -> 22092384
1@ -> 11648

2@ -> 105544526464784
3@ -> 12958305600
4@ -> 132192
5@ -> 55834642352

6@ -> WAPainterVisitor
7@ -> 132208
8@ -> 60129544128
9@ -> 84632912

10@ -> 26306545120
11@ -> 1553472491356928
12@ -> 60129675200
13@ -> 9264

14@ -> 12885099953
15@ -> #'WARenderNotification'->WARenderNotification
16@ -> anExecBlock

17@ -> anExecBlock
18@ -> 22092386
19@ -> 22092128
20@ -> 261120

... and it is size 20. so I think I'd like to see the values of the fields in both of the methods that you are seeing ...

In the mean time, I will start working on getting a "normal continuation" under the inspector and then see if I can trivially reproduce your problem ...

Dale

Mariano Martinez Peck

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

On Wed, Jun 11, 2014 at 3:53 PM, Dale Henrichs <[hidden email]> wrote:

Regarding the different sizes. The compiled method itself shows up as size 20 (as in previous mail) and here's the method context from a live stack (of size 29 ... note that the oops are the same):

--------------------
. -> aGsNMethod
.. -> WATaskVisitor>>visitTask: @5 line 5
(class)@ -> GsNMethod
(oop)@ -> 231635201

debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561
inClass@ -> WATaskVisitor
selector@ -> 22092384
1@ -> 11648
2@ -> 105544526464784
3@ -> 12958305600

4@ -> 132192
5@ -> 55834642352
6@ -> WAPainterVisitor
7@ -> 132208
8@ -> 60129544128
9@ -> 84632912

10@ -> 26306545120
11@ -> 1553472491356928
12@ -> 60129675200
13@ -> 9264
14@ -> 12885099953
15@ -> #'WARenderNotification'->WARenderNotification

16@ -> anExecBlock
17@ -> anExecBlock1
18@ -> nil
19@ -> aGsNativeCode
20@ -> 0
21@ -> 22092386

22@ -> WATaskErrorFunctionalTest
23@ -> aGsNativeCode
24@ -> 0
25@ -> 22092128
26@ -> ExecBlock
27@ -> aGsNativeCode

28@ -> 0
29@ -> 261120

and here's the block context from within the visitTask: method (of size 8):

[] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4aGsNMethod/

--------------------
. -> aGsNMethod
.. -> [] in ExecBlock0(WATaskVisitor)>>visitTask: @2 line 4
(class)@ -> GsNMethod
(oop)@ -> 250091265

debugInfo@ -> anArray( 805306624, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotification...
iFields1@ -> 15762598695796992
inClass@ -> aGsNMethod

selector@ -> 29216
1@ -> 14568529071472
2@ -> 1610483264
3@ -> 8589936576
4@ -> 131744
5@ -> WATaskErrorFunctionalTest

6@ -> aGsNativeCode
7@ -> 0
8@ -> 1825664

The oop in this case is the oop of the "block"...

OK..... you are right, it was my bad.

So in looking at your stack trace only the visitTask: block is on the stack and the visitTask: method itself is not on the stack ... so that is why you are getting the error ...

Exactly!!!! I only have the block of the #visitTask, and not the compiled method, and yes this is the cause of why I am seeing this error.

To get this info, I am simply running the WATaskErrorFunctional test and in this case both the block and the method are on the stack ...

Soooooo, if you could provide me with the code for a component that reproduces the problem, I'll be able to make progress on finding a solution ...

I am trying to investigate which is the cause and I already got an isolated case. But... I can confirm you this is related to having sub-tasks. Right now my failing scenario was this:

1) XXX's #go calls a subtask ZZZ

2) When ZZZ finished, XXX's #go calls a component TTT.

That last call from XXX's #go to component TTT is what fails. What is interesting, however, is that if I remove step 1, that is, the call to the subtask ZZZ, then it works perfect. So it has to do for sure with the fact of calling a subtask from within a task.

I will make a couple of stabs at trying to build such a component, but you are much closer to the real problem than I am ... I'm guessing that the problem is somehow related to details of the block structure on the stack, since Otto was able to reformulate his method to make the problem "go away" ...

Here it is. It is very very simple and it reproduces the problem. To test it...somewhere do a "call:TestMainTask new".

Something to note is that subtask is STORED as instVar in maintask and MainTask does implement #children with it. This is to solve the other issue you saw related to task calling tasks: https://code.google.com/p/seaside/issues/detail?id=744 and yes, I was having this problem in both Pharo and GemStone.

Let me know how it goes.

Dale

On Wed, Jun 11, 2014 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Okay, now that I'm focussing on this problem:) The fact that you have two unique instances of #visitTask: _is_ diagnostic....

Is it possible that the method was recompiled at some point in time?

Hmm, in my image when I inspect the visitTask: method I get this:

. -> aGsNMethod

(class)@ -> GsNMethod
(oop)@ -> 231635201
(invariant)@ -> true
debugInfo@ -> anArray( 1610613249, 'visitTask: aTask super visitTask: aTask. aTask isExecuting ifFalse: [ [ aTask execute ] on: WARenderNotificatio...

iFields1@ -> 13511760954786561
inClass@ -> WATaskVisitor
selector@ -> 22092384
1@ -> 11648

2@ -> 105544526464784
3@ -> 12958305600
4@ -> 132192
5@ -> 55834642352

6@ -> WAPainterVisitor
7@ -> 132208
8@ -> 60129544128
9@ -> 84632912

10@ -> 26306545120
11@ -> 1553472491356928
12@ -> 60129675200
13@ -> 9264

14@ -> 12885099953
15@ -> #'WARenderNotification'->WARenderNotification
16@ -> anExecBlock

17@ -> anExecBlock
18@ -> 22092386
19@ -> 22092128
20@ -> 261120

... and it is size 20. so I think I'd like to see the values of the fields in both of the methods that you are seeing ...

In the mean time, I will start working on getting a "normal continuation" under the inspector and then see if I can trivially reproduce your problem ...

Dale

--
Mariano
http://marianopeck.wordpress.com

TestsTasks-MarianoMartinezPeck.1.mcz (1K) Download Attachment

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

Mariano

I have hooked up your tasks and got a stack[1] that is not quite exactly matching the one that you sent earlier, but it does have the `19. [] in ExecBlock(WATaskVisitor)>>visitTask: @2 line 4` on the stack without the parent method ... so this is probably close enough to work with ... the continuation/vm expert is on vacation this week, but I've got a couple of things that I will try, now that I've got my hands on this...

Dale

[1] 1. WAGemStoneProductionErrorHandler(WAErrorHandler)>>saveExceptionContinuation: @10 line 7
2. WAGemStoneProductionErrorHandler>>handleDefault: @2 line 3
3. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleError: @2 line 2
4. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleGemStoneException: @4 line 4
5. WAGemStoneProductionErrorHandler(WAHtmlHaltAndErrorHandler)>>handleException: @2 line 2
6. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 5
7. WAGemStoneProductionErrorHandler(ExecBlock)>>on:do: @3 line 42
8. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 8
9. [] in ExecBlock>>on:do: @4 line 49
10. WAGsInvalidCallbackContext(AbstractException)>>_executeHandler: @3 line 8
11. WAGsInvalidCallbackContext(AbstractException)>>_signalWith: @1 line 1
12. WAGsInvalidCallbackContext(AbstractException)>>signal: @3 line 7
13. WAGsInvalidCallbackContext class(AbstractException class)>>signal: @3 line 4
14. GRGemStonePlatform>>seasideSuspendFlowDo: @5 line 4
15. TestMainTask(WAComponent)>>wait: @3 line 3
16. TestMainTask(WAComponent)>>call: @2 line 4
17. TestMainTask>>go @6 line 4
18. TestMainTask(WATask)>>execute @2 line 7
19. [] in ExecBlock(WATaskVisitor)>>visitTask: @2 line 4
20. ExecBlock>>on:do: @3 line 42
21. GsNMethod class>>_noopReturnTos @1 line 1
22. TestSubTask(WATask)>>accept: @2 line 2
23. WATaskVisitor(WAVisitor)>>visit: @2 line 2
24. WAVisiblePresenterGuide(WAPresenterGuide)>>visitPainter: @3 line 2
25. WAVisiblePresenterGuide(WAPainterVisitor)>>visitPresenter: @2 line 2
26. WAVisiblePresenterGuide>>visitPresenter: @2 line 2
27. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2
28. WAVisiblePresenterGuide(WAPainterVisitor)>>visitTask: @2 line 2
29. TestSubTask(WATask)>>accept: @2 line 2
30. WAVisiblePresenterGuide>>visitDecoration: @6 line 4
31. WAAnswerHandler(WADecoration)>>accept: @2 line 2
32. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2
33. TestSubTask(WAComponent)>>acceptDecorated: @2 line 2
34. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2
35. [] in WAVisiblePresenterGuide>>visitPresenter: @2 line 3
36. [] in TestMainTask(WAPresenter)>>childrenDo: @11 line 8
37. Array(Collection)>>do: @5 line 10
38. TestMainTask(WAPresenter)>>childrenDo: @3 line 2
39. WAVisiblePresenterGuide>>visitPresenter: @3 line 3
40. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2
41. WAVisiblePresenterGuide(WAPainterVisitor)>>visitTask: @2 line 2
42. TestMainTask(WATask)>>accept: @2 line 2
43. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2
44. TestMainTask(WAComponent)>>acceptDecorated: @2 line 2
45. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2
46. [] in WAVisiblePresenterGuide>>visitPresenter: @2 line 3
47. [] in TestMainComponent(WAPresenter)>>childrenDo: @11 line 8
48. Array(Collection)>>do: @5 line 10
49. TestMainComponent(WAPresenter)>>childrenDo: @3 line 2
50. WAVisiblePresenterGuide>>visitPresenter: @3 line 3
51. WAVisiblePresenterGuide(WAPainterVisitor)>>visitComponent: @2 line 2
52. TestMainComponent(WAComponent)>>accept: @2 line 2
53. WAVisiblePresenterGuide>>visitDecoration: @6 line 4
54. WAToolDecoration(WADecoration)>>accept: @2 line 2
55. WAVisiblePresenterGuide(WAPainterVisitor)>>visitDecorationsOfComponent: @3 line 2
56. TestMainComponent(WAComponent)>>acceptDecorated: @2 line 2
57. WAVisiblePresenterGuide(WAPresenterGuide)>>visit: @2 line 2
58. WAVisiblePresenterGuide(WAVisitor)>>start: @2 line 2
59. WAInitialRenderLoopContinuation>>prepareRoot: @9 line 5
60. WAInitialRenderLoopContinuation>>basicPerformAction @7 line 5
61. [] in WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2
62. WAInitialRenderLoopContinuation(ExecBlock)>>onException:do: @2 line 66
63. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @5 line 47
64. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3
65. [] in ExecBlock(WARenderLoopContinuation)>>withNotificationHandlerDo: @2 line 20
66. ExecBlock>>on:do: @3 line 42
67. WAInitialRenderLoopContinuation(WARenderLoopContinuation)>>withNotificationHandlerDo: @8 line 21
68. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2
69. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>handleFiltered: @2 line 2
70. [] in WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @3 line 4
71. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42
72. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4
73. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5
74. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12
75. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6
76. WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @2 line 4
77. [] in WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @2 line 5
78. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42
79. WAInitialRenderLoopContinuation(WASessionContinuation)>>withUnregisteredHandlerDo: @2 line 3
80. WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @4 line 5
81. WASession>>start @6 line 2
82. [] in WASession>>handleFiltered: @2 line 15
83. WAMergedRequestFields>>at:ifAbsent: @3 line 6
84. WASession>>handleFiltered: @16 line 14
85. [] in WASession(WARequestHandler)>>handle: @3 line 4
86. WASession(ExecBlock)>>on:do: @3 line 42
87. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4
88. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5
89. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12
90. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6
91. WASession(WARequestHandler)>>handle: @2 line 4
92. WASession>>handle: @10 line 11
93. WAApplication(WARegistry)>>dispatch:to:key: @4 line 6
94. WAApplication(WARegistry)>>handle:registering: @4 line 7
95. WAApplication>>handleDefault: @3 line 2
96. WAApplication(WARegistry)>>handleFiltered: @7 line 6
97. WAApplication>>handleFiltered: @10 line 8
98. WAExceptionFilter(WARequestFilter)>>handleFiltered: @3 line 4
99. [] in WAExceptionFilter>>handleFiltered: @2 line 7
100. WAExceptionFilter(ExecBlock)>>on:do: @3 line 42
101. WACurrentExceptionHandler class(WADynamicVariable class)>>use:during: @2 line 4
102. [] in WAExceptionFilter>>handleFiltered: @2 line 6
103. WAExceptionFilter(ExecBlock)>>onException:do: @2 line 66
104. WAExceptionFilter(ExecBlock)>>on:do: @5 line 47
105. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3
106. WAExceptionFilter>>handleFiltered: @5 line 4
107. [] in WAApplication(WARequestHandler)>>handle: @3 line 4
108. WAApplication(ExecBlock)>>on:do: @3 line 42
109. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4
110. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5
111. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12
112. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6
113. WAApplication(WARequestHandler)>>handle: @2 line 4
114. WADispatcher>>handleFiltered:named: @3 line 5
115. WADispatcher>>handleFiltered: @8 line 6
116. [] in WADispatcher(WARequestHandler)>>handle: @3 line 4
117. WADispatcher(ExecBlock)>>on:do: @3 line 42
118. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4
119. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5
120. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12
121. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6
122. WADispatcher(WARequestHandler)>>handle: @2 line 4
123. WADispatcher>>handleFiltered:named: @3 line 5
124. WADispatcher>>handleFiltered: @8 line 6
125. [] in WADispatcher(WARequestHandler)>>handle: @3 line 4
126. WADispatcher(ExecBlock)>>on:do: @3 line 42
127. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4
128. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5
129. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12
130. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6
131. WADispatcher(WARequestHandler)>>handle: @2 line 4
132. [] in WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @3 line 4
133. WAGsZincAdaptor(ExecBlock)>>on:do: @3 line 42
134. WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @2 line 5
135. WAGsZincAdaptor(WAServerAdaptor)>>handle: @2 line 4
136. [] in WAGsZincAdaptor(WAServerAdaptor)>>process: @2 line 6
137. WAGsZincAdaptor(ExecBlock)>>ensure: @2 line 12
138. WAGsZincAdaptor(WAServerAdaptor)>>process: @4 line 7
139. [] in WAGsZincAdaptor>>process: @2 line 6
140. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @2 line 11
141. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42
142. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @11 line 12
143. GRGemStonePlatform(ExecBlock)>>ensure: @2 line 12
144. TransientRecursionLock>>critical: @11 line 12
145. GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @3 line 5
146. [] in GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @6 line 9
147. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42
148. GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @2 line 17
149. WAGsZincAdaptor>>process: @3 line 4
150. ZnSeasideServerAdaptorDelegate>>handleRequest: @3 line 4
151. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @7 line 12
152. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateRequest:do: @4 line 6
153. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @2 line 8
154. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 5
155. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42
156. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 6
157. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequest: @5 line 9
158. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeOneRequestResponseOn: @6 line 10
159. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @2 line 10
160. [] in ZnCurrentServer class(DynamicVariable class)>>value:during: @3 line 9
161. ZnCurrentServer class(ExecBlock)>>ensure: @2 line 12
162. ZnCurrentServer class(DynamicVariable class)>>value:during: @6 line 10
163. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @4 line 8
164. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 12
165. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42
166. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 13
167. ZnManagingMultiThreadedServer(ExecBlock)>>ensure: @2 line 12
168. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 15
169. [] in ExecBlock>>ifCurtailed: @2 line 6
170. ExecBlock>>ensure: @2 line 12
171. ZnManagingMultiThreadedServer(ExecBlock)>>ifCurtailed: @3 line 8
172. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 18
173. GsProcess>>_start @7 line 16
174. UndefinedObject(GsNMethod class)>>_gsReturnToC @1 line 1

Dale Henrichs-3

Re: [GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

In reply to this post by Dale Henrichs-3

Mariano,

Today might be your luck day ... I made the following change to GRGemStonePlatform>>callbackMarker and your example with nested tasks is "working":

callbackMarker
| level aFrame visitTaskMethod |
visitTaskMethod := WATaskVisitor compiledMethodAt: #'visitTask:'.
level := 1.
[ (aFrame := GsProcess _frameContentsAt: level) ~~ nil ]
    whileTrue: [
      (((aFrame at: 10) isKindOf: WACallback)
        or: [ (aFrame at: 1) homeMethod == visitTaskMethod ])
        ifTrue: [ ^ aFrame at: 1 ].
      level := level + 1 ].
^ nil

I ran my tests in 3.2, but this should "work" in 3.1 as well ...

I keep saying "work" because I haven't put a lot of miles on this change ... but at the end of the day if it works well for you I can include this in a future Grease release ...

Enjoy,

Dale

On Mon, Jun 9, 2014 at 3:48 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,
IIRC, in Otto's case we discovered that had some "oddly" constructed blocks on the stack ... a close reading of the stack showed that when the continuation was reified on the stack, a frame (the one with the WATask method) was missing ...

Otto resolved the problem by rewriting his method a bit[1] ... so there is a bug out there, but we have not been able to get a sample into the lab, where we can dissect it and come up with a solution ...

In the sequence of three messages starting here[2], I describe some things to do and some suspicions of mine based on studying Otto's stack ...

a stack would help me determine if your bug is in the same ballpark as Otto's...

Dale

[1] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759814.html

[2] http://forum.world.st/Glass-callbackMarker-not-found-in-Seaside-stack-tp4759520p4759613.html

On Mon, Jun 9, 2014 at 1:51 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I have a working code in Pharo but in GemStone I get an error:

a WAGsInvalidCallbackContext occurred (error 2710), You can only #call: and #answer: from within a callback or a Task.

I have a WATask subclass where at certain point I do:

comp := MyComponent new.
self call: comp

That call: is the one that yields the problem... and of course, self IS KIND OF WATask for sure, so the error message does not look accurate to me. Note that I have already used tasks in other places...but this one is the first to fire this problem.

I saw another thread from Otto but I don't see if this is related and in either case, I didn't see a solution in that thread.

Debugging I note that of course, #callbackMarker is answering nil. Also, I DO see #visitTask: compiled method in the stack. But... (I guess this has nothing to do but just in case).. if I inspect the method of the context with the #visitTask: and I do a #method (to get the GsMethod), that method answers the same _sourceString as (WATaskVisitor compiledMethodAt: #visitTask:). However, they are not #= nor #==. One is size 8 and the other one 19...

Anyway....any ideas of what the problem could be?

Thanks in advance,

--
Mariano
http://marianopeck.wordpress.com