[Glass] Spurious 'You can only #call: and #answer: from within a callback or a Task.'?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] Spurious 'You can only #call: and #answer: from within a callback or a Task.'?

Pieter Nagel-3
We have a single specific callback that causes the spurious error message
'You can only #call: and #answer: from within a callback or a Task.'

The offending call: occurs within a polymorphically overidden method. The
implementation on one class works, another doesn't; both called from the
same code and the same callback.

I captured the stacktrace from both the working and failing case.

The error message is generated because GRGemStonePlatform>>callbackMarker
scans the stack for a receiver that isKindOf: WACallback, and fails to.

In the working case, the stack looks like this (edited for brevity, full
stacks attached):

---
6 AdvisorList >> addForm: (envId 0) @2 line 2
7 RoleList >> add (envId 0) @6 line 4
8 GRDelayedSendMessage >> basicPerformFor:withArguments: (envId 0) @6 line 3
9 GRDelayedSendMessage >> valueFor:withPossibleArguments: (envId 0) @12
line 10
10 GRDelayedSend >> valueWithPossibleArguments: (envId 0) @2 line 2
        receiver [448629249 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: anAdvisorList selector: #'add'
                receiver [445262337 sz: 16 cls: 122689281 AdvisorList] anAdvisorList
                message [448621569 sz: 1 cls: 46992385 GRUnboundMessage] selector: #'add'
        anArray [449361409 sz: 1 cls: 66817 Array] anArray( ...)

11 GsNMethod class >> _noopReturnTos (envId 0) @1 line 1
        receiver [144897 sz: 19 cls: 731393 GsNMethod class] GsNMethod

12 WACallback >> evaluateWithFieldValues: (envId 0) @4 line 2
        receiver [449081345 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
                key [449081601 sz: 2 cls: 74753 String] '19'
                block [450095617 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: aSearchBox selector: #'search'
        anOrderedCollection [450083329 sz: 1 cls: 66817 Array] anArray( ...)

13 [] in  WACallbackRegistry >> handle: (envId 0) @4 line 10
        receiver [450083073 sz: 5 cls: 128001 ExecBlock1] anExecBlock1
        callback [449081345 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
        fields [450082817 sz: 1 cls: 119135489 WAMergedRequestFields]
aWAMergedRequestFields
---

In other words, at frame 13 line 10 of WACallbackRegistry>>handle:
WACallback>>evaluateWithFieldValues was called on aWAActionCallback, and
it appears on the stack, as GRGemStonePlatform>>callbackMarker expects.

In the failing case, the stack looks like this:

---

6 BrokerageList >> addForm: (envId 0) @4 line 4
7 RoleList >> add (envId 0) @6 line 4
8 GRDelayedSendMessage >> basicPerformFor:withArguments: (envId 0) @6 line 3
9 GRDelayedSendMessage >> valueFor:withPossibleArguments: (envId 0) @12
line 10
10 GRDelayedSend >> valueWithPossibleArguments: (envId 0) @2 line 2
        receiver [454278913 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: aBrokerageList selector: #'add'
                receiver [445261825 sz: 16 cls: 122670081 BrokerageList] aBrokerageList
                message [454272001 sz: 1 cls: 46992385 GRUnboundMessage] selector: #'add'
        anArray [455002113 sz: 1 cls: 66817 Array] anArray( ...)

11 GsNMethod class >> _noopReturnTos (envId 0) @1 line 1
        receiver [144897 sz: 19 cls: 731393 GsNMethod class] GsNMethod

12 [] in  WACallbackRegistry >> handle: (envId 0) @4 line 10
        receiver [455994113 sz: 5 cls: 128001 ExecBlock1] anExecBlock1
        callback [456068353 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
        fields [455993857 sz: 1 cls: 119135489 WAMergedRequestFields]
aWAMergedRequestFields
---

In other words, from the exact same step-point in
WACallbackRegistry>>handle: aWAActionCallback was called again, and yet it
does not appear on the stack this time.

Is this maybe a symptom of the inside of
WACallback>>evaluateWithFieldValues being optimized away so it does not
appear on the stack? Maybe by the native code JIT?
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

failing.txt (68K) Download Attachment
working.txt (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Spurious 'You can only #call: and #answer: from within a callback or a Task.'?

Dale Henrichs-3
Pieter,

I'll need to put this issue on the stack until other engineers have returned from vacation to discuss the theoretical implications, but as is always the case, a reproducable test case that we can put our hands on, will go a long way to understanding the failure mechanism and more importantly allowing us to test out proposed solutions ...

Dale


On Thu, Mar 27, 2014 at 8:09 AM, Pieter Nagel <[hidden email]> wrote:
We have a single specific callback that causes the spurious error message
'You can only #call: and #answer: from within a callback or a Task.'

The offending call: occurs within a polymorphically overidden method. The
implementation on one class works, another doesn't; both called from the
same code and the same callback.

I captured the stacktrace from both the working and failing case.

The error message is generated because GRGemStonePlatform>>callbackMarker
scans the stack for a receiver that isKindOf: WACallback, and fails to.

In the working case, the stack looks like this (edited for brevity, full
stacks attached):

---
6 AdvisorList >> addForm: (envId 0) @2 line 2
7 RoleList >> add (envId 0) @6 line 4
8 GRDelayedSendMessage >> basicPerformFor:withArguments: (envId 0) @6 line 3
9 GRDelayedSendMessage >> valueFor:withPossibleArguments: (envId 0) @12
line 10
10 GRDelayedSend >> valueWithPossibleArguments: (envId 0) @2 line 2
        receiver [448629249 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: anAdvisorList selector: #'add'
                receiver [445262337 sz: 16 cls: 122689281 AdvisorList] anAdvisorList
                message [448621569 sz: 1 cls: 46992385 GRUnboundMessage] selector: #'add'
        anArray [449361409 sz: 1 cls: 66817 Array] anArray( ...)

11 GsNMethod class >> _noopReturnTos (envId 0) @1 line 1
        receiver [144897 sz: 19 cls: 731393 GsNMethod class] GsNMethod

12 WACallback >> evaluateWithFieldValues: (envId 0) @4 line 2
        receiver [449081345 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
                key [449081601 sz: 2 cls: 74753 String] '19'
                block [450095617 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: aSearchBox selector: #'search'
        anOrderedCollection [450083329 sz: 1 cls: 66817 Array] anArray( ...)

13 [] in  WACallbackRegistry >> handle: (envId 0) @4 line 10
        receiver [450083073 sz: 5 cls: 128001 ExecBlock1] anExecBlock1
        callback [449081345 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
        fields [450082817 sz: 1 cls: 119135489 WAMergedRequestFields]
aWAMergedRequestFields
---

In other words, at frame 13 line 10 of WACallbackRegistry>>handle:
WACallback>>evaluateWithFieldValues was called on aWAActionCallback, and
it appears on the stack, as GRGemStonePlatform>>callbackMarker expects.

In the failing case, the stack looks like this:

---

6 BrokerageList >> addForm: (envId 0) @4 line 4
7 RoleList >> add (envId 0) @6 line 4
8 GRDelayedSendMessage >> basicPerformFor:withArguments: (envId 0) @6 line 3
9 GRDelayedSendMessage >> valueFor:withPossibleArguments: (envId 0) @12
line 10
10 GRDelayedSend >> valueWithPossibleArguments: (envId 0) @2 line 2
        receiver [454278913 sz: 2 cls: 47070721 GRDelayedSend] aGRDelayedSend
receiver: aBrokerageList selector: #'add'
                receiver [445261825 sz: 16 cls: 122670081 BrokerageList] aBrokerageList
                message [454272001 sz: 1 cls: 46992385 GRUnboundMessage] selector: #'add'
        anArray [455002113 sz: 1 cls: 66817 Array] anArray( ...)

11 GsNMethod class >> _noopReturnTos (envId 0) @1 line 1
        receiver [144897 sz: 19 cls: 731393 GsNMethod class] GsNMethod

12 [] in  WACallbackRegistry >> handle: (envId 0) @4 line 10
        receiver [455994113 sz: 5 cls: 128001 ExecBlock1] anExecBlock1
        callback [456068353 sz: 2 cls: 118268417 WAActionCallback] aWAActionCallback
        fields [455993857 sz: 1 cls: 119135489 WAMergedRequestFields]
aWAMergedRequestFields
---

In other words, from the exact same step-point in
WACallbackRegistry>>handle: aWAActionCallback was called again, and yet it
does not appear on the stack this time.

Is this maybe a symptom of the inside of
WACallback>>evaluateWithFieldValues being optimized away so it does not
appear on the stack? Maybe by the native code JIT?
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass