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

[Dale Henrichs]

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 <pieter at nagel.co.za> 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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140328/996c4fe3/attachment.html>