Re: Disable testThreadedBacktrace on ! ia32

[Mike Cvet <mcvet at redhat dot com>]

On Mon, 2006-09-25 at 10:44 +0200, Mark Wielaard wrote:
> Hi Yao,
> 
> On Mon, 2006-09-25 at 13:50 +0800, Yao Qi wrote:
> > a) function name is "clone" instead of "__clone"
> > I add some "System.err.println" in this case, and here is the output,
> > 
> > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.ComparisonFailure:
> > expected:<__...> but was:<...>
> >    at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner)
> >    at
> > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner)
> >    at frysk.junit.Runner.<init>(TestRunner)
> >    at TestRunner.main(TestRunner)
> > 
> > FAILURES!!!
> > Tests run: 2,  Failures: 1,  Errors: 0
> > 
> > It seems that output is "clone" instead of "__clone".  Does the
> > function name vary from different versions of library?  I do not know
> > what happened on your box when run this case, so I do not change
> > "__clone" to "clone" in this case.
> 
> Interesting. I tested on x86 (FC development 2.6.18-1.2689.fc6, gcc
> 4.1.1 20060920). And indeed I also get __clone there. Mike, what kind of
> system are you using?
> 

I'm using FC5 2.6.17-1.2187_FC5 with GCC 4.1.1 20060525.

> > b) Compilation flags to test case affect the result.
> > If we compile funit-rt-threader without "-g", the result is like this,
> > Time: 0.341
> > There was 1 error:
> > 1)
> > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)java.lang.NullPointerException
> >    at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner)
> >    at
> > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner)
> >    at frysk.junit.Runner.<init>(TestRunner)
> >    at TestRunner.main(TestRunner)
> > There was 1 failure:
> > 1)
> > testBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError:
> > expected:<61> but was:<62>
> >    at frysk.rt.tests.TestStackBacktrace.testBacktrace(TestRunner)
> >    at frysk.junit.Runner.<init>(TestRunner)
> >    at TestRunner.main(TestRunner)

What is interesting about this one that that 62 is the *correct* line
number that libunwind should be pulling out, but I can't figure out why
it gives me one line less than it should. This is after my fix for the
innermost frames/signal frames memory address decrement. Strange that it
appears to be giving the correct line number on your system. I'll file a
bug and fix up the test case regarding this.

> 
> That seems to be what Tim is also seeing. Using -g to compile moves the
> actual debug info/line number by one.

/me wonders what is going on!