Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1

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

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