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

[Marco Trudel]

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?
> 
>