From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24703 invoked by alias); 21 May 2009 18:53:44 -0000 Received: (qmail 24684 invoked by uid 22791); 21 May 2009 18:53:43 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_46,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mail-ew0-f157.google.com (HELO mail-ew0-f157.google.com) (209.85.219.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 May 2009 18:53:33 +0000 Received: by ewy1 with SMTP id 1so1537877ewy.8 for ; Thu, 21 May 2009 11:53:30 -0700 (PDT) Received: by 10.210.13.17 with SMTP id 17mr3644028ebm.83.1242932004966; Thu, 21 May 2009 11:53:24 -0700 (PDT) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 10sm150948eyz.11.2009.05.21.11.53.11 (version=SSLv3 cipher=RC4-MD5); Thu, 21 May 2009 11:53:11 -0700 (PDT) Message-ID: <4A15A5CD.1000209@gmail.com> Date: Thu, 21 May 2009 18:53:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bryce McKinlay CC: Dave Korn , java@gcc.gnu.org Subject: Re: Question about a comment in _Jv_StackTrace::UnwindTraceFn References: <4A15890E.30001@gmail.com> <7230133d0905211017q18062036s9f42f29ea15bebd8@mail.gmail.com> In-Reply-To: <7230133d0905211017q18062036s9f42f29ea15bebd8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00057.txt.bz2 Bryce McKinlay wrote: > On Thu, May 21, 2009 at 6:02 PM, Dave Korn > 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