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:
Locked
