Static builds vs. printStackTrace info (was Re: AccessController speedup)

Tue Aug 29 06:08:00 GMT 2006

Maybe that has changed in the last 2 months, but back then, it worked if 
you didn't strip the binary (remove "-s"), added debugging support (add 
"-g" and had addr2line in PATH.
But as I said, it might be different now...
Marco
Scott Gilbertson wrote:
> 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?
>>