Arnaud Weber reports that with ladybird b17, with the suspend/resume
fixes he gets empty GetCallTraces:

Extracts from his email:


    I have a good news and a bad news. The good news is that the JVMPI
implementation in the last JDK 1.3.1 public beta release is stable enough to
support OptimizeIt with a few restrictions. Early March we'll release OptimizeIt
4.02 on both Windows and Solaris. 4.02 will be our first release officially
supporting Hotspot on both Windows and Solaris. Many customers have been waiting
for this for a long time especially on Solaris where JDK 1.3 profiling was
impossible. Thanks a lot for the great work!

    The bad news is that JDK 1.3.1 B17 includes a new bug which basically breaks
our profiler. Also, we are concerned by JVMPI overhead with hotspot. I have
included some detailed description of both issues below. As usual, please let me
know if you need more information.

JDK 1.3.1 B17
----------------

The issue #3 below no longer occurs, however, a new bug causes profiling to be
unusable. This problem occurs both on Solaris and Windows:

If a thread calls GetCallTrace() for another thread, GetCallTrace always
returns an empty backtrace.
The code below use to work in previous version of JDK 1.3.1 as well as the
classic runtime. For example it works with JDK 1.3.1 public beta:

    JVMPI_CallTrace *buffer;
    ...
   buffer->env_id = anotherThreadJNIEnv;
   buffer->num_frames = 0;
  (*oiipi->GetCallTrace)(buffer, length);
    ...

If GetCallTrace() is called for the calling thread JNIEnv, it works as expected.
If it is called for any other thread, it always returns an empty stack trace.
This new bug is a showstopper for us because our sampling based profiler is
unusable. Also, we cannot think of any way to workaround this issue.

> > 3) Calling GetCallTrace on a thread that has been suspended with
> > SuspendThread() often results in a deadlock in the 1 frame down the
> > GetCallTrace call. Our workaround is to resume the thread right before
> > calling GetCallTrace. Unfortunately, we now get some rare crashes
> > within GetCallTrace. Crasher stacktrace is:
> > JVM! 50484cab()
> > JVM! 5045bb35()
> > JVM! 5045bd53()
> > Fixing either the crash or the deadlock would work for us. The best
> > choice for us would be to fix the deadlock
Basically, A simple JVMPI handler, implements a trivial sampling thread that
displays on stdout the number of call trace GetCallTrace returns.
A simple Java program, starts the simple sampler and then forever wait 1s before
performing some computation.

Running this test program demonstrates that with b17 GetCallTrace always return
an empty stack trace. It is compiled for windows but can obviously be ported to
solaris (the bug exists on both windows and solaris)