Bug 3071 - libunwind is trying to access the memory address 0x0
Summary: libunwind is trying to access the memory address 0x0
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Andrew Cagney
Depends on:
Blocks: 2936 3076
  Show dependency treegraph
Reported: 2006-08-15 18:12 UTC by Adam Jocksch
Modified: 2006-10-06 05:24 UTC (History)
5 users (show)

See Also:
Last reconfirmed:

Patch that avoids returning a null pointer that will later be unconditionally dereferenced (228 bytes, patch)
2006-09-04 04:00 UTC, Alexandre Oliva
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jocksch 2006-08-15 18:12:30 UTC
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.
Comment 1 Alexandre Oliva 2006-08-18 08:47:24 UTC
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
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 ----


Time: 0.009

OK (1 test)

Comment 2 Alexandre Oliva 2006-09-04 04:00:53 UTC
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.
Comment 3 Alexandre Oliva 2006-10-06 05:24:08 UTC
This has been fixed for a while.