|Product:||frysk||Reporter:||Mike Cvet <mcvet>|
|Component:||general||Assignee:||Mike Cvet <mcvet>|
|Bug Depends on:|
Description Mike Cvet 2006-12-08 20:59:17 UTC
testRecursiveLineStepping(frysk.rt.tests.TestStepping)junit.framework.AssertionFailedError: expected:<67> but was:<244> The test program is funit-rt-threadstepper.c The previous line is 66, which is inside an infinitely recursive function. Line 244 is the last line of main(). Seems to appear only on i386, not on x86_64. Weird.
Comment 1 Mike Cvet 2006-12-11 15:33:43 UTC
The readelf .debug_line output of the funit-rt-threadstepper binary lists: Special opcode 6: advance Address by 0 to 0x8048b86 and Line by 1 to 238 Advance PC by 36 to 0x8048baa Special opcode 7: advance Address by 0 to 0x8048baa and Line by 2 to 240 Special opcode 77: advance Address by 5 to 0x8048baf and Line by 2 to 242 Advance PC by 74 to 0x8048bf9 Special opcode 7: advance Address by 0 to 0x8048bf9 and Line by 2 to 244 Advance PC by constant 17 to 0x8048c0a Extended opcode 1: End of Sequence The PC of the task trying exit above is 0x8048c0a. Its program counter earlier on appears to be correct, before changing to some memory addresses unlisted by the readelf output, and then 0x8048c0a which is beyond the end of main(). Happens on the main thread and a secondary thread which are recursively looping; the third thread stuck on a while(1) loop is fine.
Comment 2 Mike Cvet 2006-12-11 20:34:10 UTC
From objdump: 08048c0a <__i686.get_pc_thunk.bx>: 8048c0a: 8b 1c 24 mov (%esp),%ebx 8048c0d: c3 ret 8048c0e: 90 nop 8048c0f: 90 nop Looks like we're catching a a thunk in the stepping. Compiling with -- asynchronous-unwind-tables mitigates the problem. Solution for now is to recognize the step into this area and re-step in an attempt to end up where we meant to.