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

AltStyle によって変換されたページ (->オリジナル) /