Re: GCJ Thread Dump

[David Daney <ddaney at avtrex dot com>]

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.