Question: Am I on the right track, diagnosing why no addresses appear in
stack traces for a static binary?
Details:
Andrew Haley wrote:
Scott Gilbertson writes:
> The only problem I've seen so far is that exception stack dumps don't
work
> (static or dynamic). I'm guessing that's because it needs TLS, which I
> think is problematic on my old glibc. Does that sound right?
That certainly sounds possible. Strictly speaking, TLS shouldn't be
required, but we don't test without it. A lot of interfaces in libgcj
really require unwinding to work. I'd debug to find out where the
problem lies.
Andrew.
Looks like "--disable-tls" is fine, and the remaining problems are specific
to static builds.
It appears to have been an observational skills problem on my part. In
fact, I'm getting the same traces with and without TLS (and TLS works on my
old linux now, which is good). I was thrown off by the absence of
"call_main" or "run" in the trace, and I see in GetStackTraceElements that
this is intentional. I modified my test program to nest a few calls before
throwing, and the trace shows all the calls both with and without TLS.
No addresses or line numbers, though -- line numbers work in a dynamic
executable (with or without TLS), but not static. I tried
"-Dgnu.gcj.runtime.NameFinder.show_raw=true" but each entry just says the
class, method and "Unknown Source". For my purposes the lack of an address
may not matter (and I guess trying for line numbers in static builds would
be pretty ambitious), but I thought I'd look into it anyhow. The working
parts (class, method) must require the part that doesn't (raw address from
the stack frame), so I figured the thing must be basically working, so maybe
the problem is something simple.
I did (with show_raw=true, in a class called "Throw"):
Throwable tt = new Throwable();
tt.fillInStackTrace();
StackTraceElement[] ee = tt.getStackTrace();
System.out.println ("Object " + tt + ", element: " + ee[0].toString());
Dynamic build (very nice):
Object java.lang.Throwable, element: Throw.main(Throw.java:9)
Static build (OK, but no addresses or line numbers):
Object java.lang.Throwable, element: Throw.main(Unknown Source)
Stripped static build (same result as when not stripped):
Object java.lang.Throwable, element: Throw.main(Unknown Source)
I would have expected, for static build, something like:
Object java.lang.Throwable, element: Throw.main [abcd1234](Unknown
Source)
It looks like the only way ee can be non-zero-length is if
VMThrowable.fillInStackTrace returns a non-zero-length array. In that case,
it should have called _Jv_StackTrace::GetStackTraceElements, which should
have called getLineNumberForFrame, which should have found *lineNum == -1 &&
NameFinder::showRaw(), so should have added an address to sourceFileName.
It didn't.
It's not obvious to me where in that process anything would be sensitive to
static vs. dynamic builds, except maybe "if (_Jv_platform_dladdr (ip,
&info))" in _Jv_StackTrace::getLineNumberForFrame, and if that wasn't
passing I wouldn't get class or method names. I've got a recent history of
missing the obvious. Am I missing something that would be obvious if I
understood this stuff better?