[GS/SS Beta] Seaside bug with WAGsInvalidCallbackContext

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

Submitted this bug[1] against glassdb/Grease for tracking...

[1] https://github.com/glassdb/Grease/issues/4

On Mon, Jun 16, 2014 at 12:09 PM, Dale Henrichs <[hidden email]> wrote:

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

On Mon, Jun 16, 2014 at 5:52 PM, Dale Henrichs <[hidden email]> wrote:

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

On Mon, Jun 16, 2014 at 4:09 PM, Dale Henrichs <[hidden email]> wrote:

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

Hi Dale,

For for debugging this. I have just tried (I use Seaside 3.0.9) and it still didn't work.

First, I would get a dnu because in the line "aFrame at: 1) homeMethod"  the #:at would answer nil for same frames. So I modified to the following version:

 

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) ifNil: [ false ] ifNotNilDo: [:gsMethod | gsMethod homeMethod == visitTaskMethod] ])

        ifTrue: [ ^ aFrame at: 1 ].

      level := level + 1 ].

  ^ nil

  

But then I get again the same error as I was getting before...

That code looks fine. I've attached the mcz with the component code as well, so we can truly compare apples to apples and let's see if you get the same results as I did ... if it works for you, then the example you sent doesn't match  your real stack well enough ... if it doesn't work for you, the the difference might be in the fact that I'm running GemStone3.2 and Seaside3.1 while you are running GemStone 3.1(?) and Seaside 3.0.9.

Hi Dale,

I have just tried the TestTasks in my GemStone 3.0.1.5 with Seaside 3.0.9 and I do get the original error that started this thread. 

 

Question...I am browsing the stack I get in GemTools... I want to inspect the context where I have the call to visitTask. But when I inspect I get a OGStackFrame. How can I get the associated Gemstone context from it?

The GemStone context is a C struct, so the OGStackFrame is about as close as you're going to get ... the `aFrame` is just an Array and the OGStackFrame wraps the Array from  #frameContentsAt: ... there is no #thisContext in GemStone ...

The patch I cam up with a pretty "cheap hack" and I was a bit surprised that it seemed to work ... but I think your example was not close enough to the real problem or Seaside3.0.9/GemStone3.1 aren't behaving quite the same ...

OK...so then maybe the problem might be the inspector. When I inspect an instance of a OGStackFrame I don't see anything...

Yes...indeed.I commented out the pragma of #debuggerInspectorNodes and now I can see the real info..

now....WTF!!!! Once I open the stack that yielded the error, I go down up to the visitTask. I inspect that context and I get a OGStackFrame. Now with that stackframe I execute:   

(frame at: 1) homeMethod == (WATaskVisitor compiledMethodAt: #visitTask:)

 

and guess what I receive???   TRUE!!!!

grrr this is strange. 

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

Okay ... let me look and see what I can figure out ... I don't think the actual partial continuation logic changed in from 3.1 to 3.2 ... but there may be other things at work here ...

I'll let you know ...

Dale

On Mon, Jun 16, 2014 at 2:12 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Mon, Jun 16, 2014 at 5:52 PM, Dale Henrichs <[hidden email]> wrote:

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

On Mon, Jun 16, 2014 at 4:09 PM, Dale Henrichs <[hidden email]> wrote:

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

Hi Dale,

For for debugging this. I have just tried (I use Seaside 3.0.9) and it still didn't work.

First, I would get a dnu because in the line "aFrame at: 1) homeMethod"  the #:at would answer nil for same frames. So I modified to the following version:

 

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) ifNil: [ false ] ifNotNilDo: [:gsMethod | gsMethod homeMethod == visitTaskMethod] ])

        ifTrue: [ ^ aFrame at: 1 ].

      level := level + 1 ].

  ^ nil

  

But then I get again the same error as I was getting before...

That code looks fine. I've attached the mcz with the component code as well, so we can truly compare apples to apples and let's see if you get the same results as I did ... if it works for you, then the example you sent doesn't match  your real stack well enough ... if it doesn't work for you, the the difference might be in the fact that I'm running GemStone3.2 and Seaside3.1 while you are running GemStone 3.1(?) and Seaside 3.0.9.

Hi Dale,

I have just tried the TestTasks in my GemStone 3.0.1.5 with Seaside 3.0.9 and I do get the original error that started this thread. 

 

Question...I am browsing the stack I get in GemTools... I want to inspect the context where I have the call to visitTask. But when I inspect I get a OGStackFrame. How can I get the associated Gemstone context from it?

The GemStone context is a C struct, so the OGStackFrame is about as close as you're going to get ... the `aFrame` is just an Array and the OGStackFrame wraps the Array from  #frameContentsAt: ... there is no #thisContext in GemStone ...

The patch I cam up with a pretty "cheap hack" and I was a bit surprised that it seemed to work ... but I think your example was not close enough to the real problem or Seaside3.0.9/GemStone3.1 aren't behaving quite the same ...

OK...so then maybe the problem might be the inspector. When I inspect an instance of a OGStackFrame I don't see anything...

Yes...indeed.I commented out the pragma of #debuggerInspectorNodes and now I can see the real info..

now....WTF!!!! Once I open the stack that yielded the error, I go down up to the visitTask. I inspect that context and I get a OGStackFrame. Now with that stackframe I execute:   

(frame at: 1) homeMethod == (WATaskVisitor compiledMethodAt: #visitTask:)

 

and guess what I receive???   TRUE!!!!

grrr this is strange. 

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