From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12320 invoked by alias); 21 May 2009 19:13:09 -0000 Received: (qmail 12308 invoked by uid 22791); 21 May 2009 19:13:09 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_52,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 May 2009 19:13:02 +0000 Received: by ey-out-1920.google.com with SMTP id 3so290080eyh.14 for ; Thu, 21 May 2009 12:12:59 -0700 (PDT) Received: by 10.210.88.3 with SMTP id l3mr3666136ebb.88.1242933173696; Thu, 21 May 2009 12:12:53 -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 7sm388526eyg.47.2009.05.21.12.12.52 (version=SSLv3 cipher=RC4-MD5); Thu, 21 May 2009 12:12:53 -0700 (PDT) Message-ID: <4A15AA6B.1090205@gmail.com> Date: Thu, 21 May 2009 19:13:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Dave Korn CC: Bryce McKinlay , java@gcc.gnu.org, Andrew Haley Subject: Re: Question about a comment in _Jv_StackTrace::UnwindTraceFn References: <4A15890E.30001@gmail.com> <7230133d0905211017q18062036s9f42f29ea15bebd8@mail.gmail.com> <4A15A5CD.1000209@gmail.com> In-Reply-To: <4A15A5CD.1000209@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/msg00058.txt.bz2 Dave Korn wrote: > 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? To half-answer my own question there, __Jv_global_static_constructor is at least being called at static ctor time, so I should be OK on most fronts. > 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. Yes, this looks like a regression. The setting of runtimeInitialized was moved to the end of the function in r115791 Revision 115791 - (view) (download) - [select for diffs] Modified Fri Jul 28 07:40:17 2006 UTC (2 years, 9 months ago) by gary File length: 45045 byte(s) Diff to previous 114300 (colored) 2006-07-28 Gary Benson * prims.cc (_Jv_CreateJavaVM): Move setting runtimeInitialized from the start to the end of the function. Remove references to VMThrowable.trace_enabled. * java/lang/natVMThrowable.cc (fillInStackTrace): Use runtimeInitialized rather than trace_enabled to decide whether to inhibit stack trace generation. * java/lang/VMThrowable.java (trace_enabled): Removed. ... and apparently re-added at the start, almost certainly inadvertently, when Tom merged the gcj-eclipse branch to trunk at r120621. I will prepare and test a patch that simply removes the re-added set at the top of the function. cheers, DaveK