GCJ Thread Dump

Thu Feb 10 14:24:00 GMT 2005

Bryce McKinlay wrote:
> Andrew Haley wrote:
>>> Mark Anderson writes:
>> > Is there any way to get a thread dump from a running GCJ application 
>> in the > same way you can send a kill -3 signal to the Sun JVM?
>>>> No, there isn't, and it would be extremely hard to do. Whan we have a
>> problem like this, we attach gdb to the process.
>>> I'm curious - why is this so difficult? I think Sun's implementation 
> shows what locks are held by each thread, along with the stack trace, 
> which might be tricky. However, I don't see why plain old thread dumps 
> would be so hard given that we can already unwind through signal 
> handlers. Note that there is a enhancement request for this:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15686
>
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. 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.
It would be much easier if everything on the system was compiled with a 
framepointer. Then backtracing would be easy.
Just my idle ramblings
David Daney.