From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26289 invoked by alias); 18 Feb 2010 15:38:40 -0000 Received: (qmail 26264 invoked by uid 22791); 18 Feb 2010 15:38:39 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f222.google.com (HELO mail-fx0-f222.google.com) (209.85.220.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 15:38:35 +0000 Received: by fxm22 with SMTP id 22so9090210fxm.16 for ; Thu, 18 Feb 2010 07:38:32 -0800 (PST) Received: by 10.223.17.92 with SMTP id r28mr12037824faa.91.1266507512193; Thu, 18 Feb 2010 07:38:32 -0800 (PST) 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 15sm4725787fxm.6.2010.02.18.07.38.28 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 07:38:29 -0800 (PST) Message-ID: <4B7D631B.8030401@gmail.com> Date: Thu, 18 Feb 2010 15:38: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 Patches , GCC Patches Subject: Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1 References: <4B6C9B26.3010106@gmail.com> <4B6D0C67.5030500@gmail.com> <4B78BA6D.5000603@gmail.com> <7230133d1002150504r23738e28if92303426c349661@mail.gmail.com> <4B7CC61E.1050709@gmail.com> In-Reply-To: <4B7CC61E.1050709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2010-q1/txt/msg00038.txt.bz2 On 18/02/2010 04:46, Dave Korn wrote: >>> * jvmti.cc (_Jv_GetJVMTIEnv): Fix use of uninitialised memory >>> exposed by the above change. >> This part is fine. > > Well: it appears to have caused a regression (investigating which is the > reason why I took a while to respond to you). I'm now seeing: > >> Running /gnu/gcc/gcc/libjava/testsuite/libjava.loader/loader.exp ... >> FAIL: /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC.exe output - /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC.exe > > *sigh*, and it turns out to be because some memory is getting released by the > garbage collector when its still in use. I'm busy trying to learn how the GC > works real fast so I can figure out what's going wrong. I'm now very sure that the problem is a side-effect of the libgcj DLL being rebased at runtime, and not related to the clearing of memory in _Jv_GetJVMTIEnv (which isn't even called in this testcase). So I'd like to go ahead with this part of the patch after all. I'll spend up to another 24 hours trying to fix the knock-on failure before I commit it, it would be nice to have the fix for that ready to go in at the same time. That still OK with you? (Also, did my explanation for the other part of the patch make sense, or do I need to go into more detail about anything?) > I was surprised to > discover that the test executable links its own entirely separate copy of the > GC library in addition to the one that's in the libjava DLL(s), is that > supposed to happen? I was wrong about this, it was a red herring caused by the fact that libgcj was getting rebased down to a runtime address so low that I thought it was in the EXE's text section; in fact it was not. I've now proven that by rebasing all the other DLLs out of the way I can make the test pass or fail just by moving around where libgcj gets loaded in the process memory space, and it fails in different ways according to where I move it to, which is symptomatic of a problem with base relocations in the generated DLL. I'm going to look at how the GC determines the extent of the DLL's data area when it looks for pointers during the mark phase, because if the static data region ranges aren't being fixed up correctly when the DLL gets rebased to a different load address at runtime, that could cause this kind of problem. cheers, DaveK