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.
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.
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.
2006-12-11 Mike Cvet <firstname.lastname@example.org>
* tests/TestStepping.java (testRecursiveLineStepping): Re-enabled.
(stepAssertions): Catch steps into non-debuginfo areas; including
linker thunk. Fixes #3685. Fixed up more assertions. Fixes #3685