When running TestStackBacktrace, it frequently aborts on first memory read (attempting to read at 0x0) with a ptrace IO error. Occaisionally it succeeds in reading the value 0 from this address and continues.
I've tried to duplicate this on FC5/x86 (with all updates and testing updates) and FC6devel/x86_64 (yesterday's rawhide), to no avail, on a frysk tree checked out from CVS yesterday, and then updated today. It at least looks like it passes for me. Here's what I get from running TestStackBacktrace on x86_64 (x86 output is identical except for addresses, timestamps and total run time). Am I misreading it? [aoliva@free frysk-core]$ ./TestRunner -c FINE frysk.rt.tests.TestStackBacktrace console FINE java.util.logging.ConsoleHandler@2e38e6bd 18-Aug-06 5:44:21 AM frysk.junit.Runner$Results startTest FINE: testBacktrace(frysk.rt.tests.TestStackBacktrace) ---- startTest ---- Running testBacktrace(frysk.rt.tests.TestStackBacktrace) ...18-Aug-06 5:44:21 AM frysk.event.EventLoop <init> FINE: {Thread[Thread-1,5,main]} new 18-Aug-06 5:44:21 AM frysk.event.EventLoop <init> FINE: {Thread[Thread-2,5,main]} new <<BROKEN http://sourceware.org/bugzilla/show_bug.cgi?id=2936 >>18-Aug-06 5:44:21 AM frysk.junit.Runner$Results endTest FINE: testBacktrace(frysk.rt.tests.TestStackBacktrace) ---- endTest ---- PASS Time: 0.009 OK (1 test)
Created attachment 1276 [details] Patch that avoids returning a null pointer that will later be unconditionally dereferenced The problem is that our get_dyn_info_list_addr() didn't ever do anything, so we ended up returning a (jlong)null pointer instead of indicating the unsupported error, and the caller would unconditionally (and rightfully) dereference the null pointer. This patch arranges for us to generate the expected error when the callback fails, but it's obviated by the patch for bug 3070.
This has been fixed for a while.