Quantcast

Assert fails on non-local return

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Assert fails on non-local return

Eliot Miranda-2
 
Hi Clément, Hi All,

    in debugging the SpurPlanningCompactor for the CoInterpreter I'm seeing a fair few stack depth check fails for non-local returns in Squeak trunk methods such as [] in SystemProgressMorph>nextSlotFor:, [] in HTTPSocket class>httpGet:args:user:passed: and [] in PackageInfo>changeRecordsForMethod:do:.

Since these assert-fails happen in methods that are fully linked I know that the problem is /not/ the non-local return.  For example, here's the code for a non-local return that fails the assert check at the end of the [] in SystemProgressMorph>nextSlotFor:

000db633: movl %edx, %esi : 89 D6 
000db635: popl %edx : 5A 
000db636: movl $0x00000c38, %ecx : B9 38 0C 00 00 
000db63b: call .+0xfff31fe4 (0x0000d624=addMorphBack:@2C) : E8 E4 1F F3 FF 
IsSendCall addMorphBack: bc 205/206:
000db640: movl -32(%ebp), %edx : 8B 55 E0 
000db643: call .+0xfff25b90 (0x000011d8=ceNonLocalReturnTrampoline) : E8 90 5B F2 FF 
IsRelativeCall:
HasBytecodePC bc 208/209:


Since the stack depth is checked when a send is linked we know that the stack depth was correct at 000db63b.  And hence it's likely that the stack depth was correct when the non-local return trampoline was called soon afterwards.  [I need to confirm this].

So this would imply that the stack depth is incorrect due to something else, and I suspect event checks on backward branches.  This non-local return is in a loop.  So its conceivable that the stack gets set incorrectly on some path through event checking.  [The stack in this context is incorrect in having an extra copy of the loop index on the stack between the temp vars and the arguments to the thisContext aboutToReturn: result through: unwind.

For now, this is just an observation, but it could be a serious bug and it would be nice to fix it  I guess we should add some assert checks on stack depth for reentering loops, e.g. in a CoInterpreter override for externalSetStackPageAndPointersForSuspendedContextOfProcess:

_,,,^..^,,,_
best, Eliot
Loading...