GCJ Thread Dump
Bryce McKinlay
mckinlay@redhat.com
Thu Feb 10 18:04:00 GMT 2005
David Daney wrote:
> As I said earlier It would probably have to be done from something
> similar to the GC's stop-the-world. You would print a stack trace for
> each thread.
>> The problem I see is that for targets that have no frame pointer.
> These have to use the DWARF .eh_frame information for generating
> stacktraces. The stop-the-world uses asynchronous signals and these
> are not compatible with DWARF exception handling.
On most platforms, we can unwind through signal handlers thanks to
MD_FALLBACK_FRAME_STATE_FOR - this is how NullPointerException is
implemented.
> It might be possible to generate enough eh_frame data to allow
> getting a stack trace from any instruction, but without adding
> everything needed for full exception handling (I don't really know not
> being an expert in this area).
>> We could compile all GC/libgcj/etc libraries with
> -fnon-call-exceptions, but what would happen for threads blocked in
> libc or system calls? I think those might be difficult to backtrace
> through.
Ah, good point - presumably this is what Andrew was referring to.
MD_FALLBACK_FRAME_STATE_FOR would fail if, say, we signaled a thread
during a glibc leaf function call which had no unwind info. Non-Linux
systems may not have unwind info for their system calls at all.
Bryce
More information about the Java
mailing list