Bug 3685 - testRecursiveLineStepping(frysk.rt.tests.TestStepping)junit.framework.AssertionFailedError
Summary: testRecursiveLineStepping(frysk.rt.tests.TestStepping)junit.framework.Asserti...
Status: RESOLVED FIXED
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Mike Cvet
URL:
Keywords:
Depends on:
Blocks: 3346
  Show dependency treegraph
 
Reported: 2006-12-08 20:59 UTC by Mike Cvet
Modified: 2006-12-11 21:26 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.
Comment 3 Mike Cvet 2006-12-11 21:26:09 UTC
2006-12-11  Mike Cvet  <mcvet@redhat.com>

	* tests/TestStepping.java (testRecursiveLineStepping): Re-enabled.
	(stepAssertions): Catch steps into non-debuginfo areas; including
	linker thunk. Fixes #3685. Fixed up more assertions. Fixes #3685
	and #3686.