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 |
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 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |