Re: Question about a comment in _Jv_StackTrace::UnwindTraceFn

[Dave Korn <dave.korn.cygwin@googlemail.com>]

Bryce McKinlay wrote:
> On Thu, May 21, 2009 at 6:02 PM, Dave Korn
> <dave.korn.cygwin@googlemail.com> wrote:
> 
>> ... but is that the right thing to do?  Where should state->interp_frame have
>> been set up?  It appears to fix testsuite failures, but I don't know for sure
>> if they're doing everything right internally.  I'll run it through a test
>> cycle if just avoiding the problem in this way is indeed correct, but a
>> pointer or two could speed me on the way or save me barking up any wrong trees.
> 
> Hi Dave
> 
> state->interp_frame is set in the _Jv_InterpFrame constructor, right
> at the top of interp-run.cc
> 
> #ifdef __GCJ_DEBUG
>   _Jv_InterpFrame frame_desc (meth, thread, NULL, &pc);
> #else
>   _Jv_InterpFrame frame_desc (meth, thread);
> #endif
> 
> _Jv_InterpFrame itself is defined in include/java-interp.h

  Okeydokey, I've watched it go through the constructor, and tag itself onto
the linked list, and it's still the only entry.  Stepping through the
interpreter we get to

514           NEXT_INSN;
(gdb)
2382            SAVE_PC();
(gdb)
2383            int index = GET2U ();
(gdb) step
2385

and that leads us through _Jv_Linker::resolve_pool_entry ->
_Jv_FindClassNoException -> _Jv_FindClass -> java.lang.ClassLoader.loadClass.

It's trying to load 'java.util.HashSet'.  It ends up calling through a bunch
of java.lang.ClassLoader methods and java::lang::VMClassLoader into
gnu.gcj.runtime.BootClassLoader.bootLoadClass which tries to open some sort of
URLConnection.  The gnu.java.net.protocol.core.Connection.connect method wants
to create a Core object:

42        // Implementation of abstract method.
43        public void connect() throws IOException
44        {
45          // Call is ignored if already connected.
46          if (connected)
47            return;
48
49          // If not connected, then file needs to be opened.
50          core = Core.create (url.getFile());

and _Jv_create_core fails.

113     gnu::gcj::Core *
114     gnu::gcj::Core::create (jstring name)
115     {
116       gnu::gcj::Core *core = _Jv_create_core (root, name);
117       if (core == NULL)
118         throw new ::java::io::IOException (JvNewStringLatin1 ("can't open co
re"));
119       return core;
120     }
(gdb)

  name is "/java/lang/Object.class".  There are no _Jv_core_chain nodes on the
root chain.  So we throw an exception.

  That proceeds smoothly through the IOException and base Exception
constructors and then reaches the Throwable constructor:


(gdb) list
156        *
157        * @param message the message to associate with the Throwable
158        */
159       public Throwable(String message)
160       {
161         fillInStackTrace();
162         detailMessage = message;
163       }
164
165       /**
(gdb)

.. which calls fillInStackTrace.  And this is where I think it's going to go
wrong:

(gdb) list
25      java::lang::VMThrowable::fillInStackTrace (java::lang::Throwable *)
26      {
27        using namespace java::lang;
28
29        // Don't trace stack during initialization of the runtime.
30        if (! gcj::runtimeInitialized)
31          return NULL;
32
33        _Jv_StackTrace *trace = _Jv_StackTrace::GetStackTrace ();
34        VMThrowable *vmthrowable = new VMThrowable ();
(gdb)
35        vmthrowable->data = (RawDataManaged *) trace;
36        return vmthrowable;
37      }

... because we're still in runtime initialisation here:

(gdb) frame 25
#25 0x004049af in _Jv_CreateJavaVM (vm_args=0x22ccb0)
    at /gnu/gcc/gcc-patched/libjava/prims.cc:1682
1682      _Jv_JNI_Init ();
(gdb) list
1677      LTDL_SET_PRELOADED_SYMBOLS ();
1678    #endif
1679
1680      _Jv_platform_initialize ();
1681
1682      _Jv_JNI_Init ();
1683
1684    #ifdef INTERPRETER
1685      _Jv_JVMTI_Init ();
1686    #endif
(gdb)


... as called from _Jv_RunMain.  But the runtimeInitialized flag was set true
right at the start of _Jv_CreateJavaVM:

1610    jint
1611    _Jv_CreateJavaVM (JvVMInitArgs* vm_args)
1612    {
1613      using namespace gcj;
1614
1615      if (runtimeInitialized)
1616        return -1;



  So, I think maybe I have *two* problems:

i)  The gcj::Core::root chain is empty.  Should it be?  Do I have a problem
with static c/dtors?  I don't have JCR_SECTIONS turned on yet, so maybe I need
to enable it?

ii) I don't think the library is able to handle an exception being thrown this
early in startup because the code that segfaults filling out the stacktrace
does assume it's inside at least one nested interpreter frame, and it wouldn't
be called at all if it wasn't for what looks like a race-condition failure of
the safety check at the top of java::lang::VMThrowable::fillInStackTrace.
Should nothing be throwing at this early stage, or should we perhaps not set
runtimeInitialized until later?  I note that it gets set true a second time,
apparently redundantly, at the very end of _Jv_CreateJavaVM, so perhaps an
accident of some sort has occurred here?  I'll take a look through the svn
history.

    cheers,
      DaveK