[Bug java/42811] New: [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[Bug java/42811] New: [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[jojelino at gmail dot com]

configuration

./configure --prefix=/usr --disable-win32-registry --enable-threads=posix
--enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls
--disable-bootstrap --enable-shared --enable-interpreter
--disable-sjlj-exceptions --enable-load-library

testcase

public class java
{ 
  public static void main(String arg[]) 
  { 
    System.out.println("Hello World!"); 
  } 
}

debug session

Reading symbols from /usr/libexec/gcc/i686-pc-cygwin/4.5.0/ecj1.exe...done.
(gdb) set args java.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.5.0.j
ar -g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency java.zip -fzip-target java.j
ar
(gdb) directory /tmp/gcc/t/t/t/t
Warning: /tmp/gcc/t/t/t/t: No such file or directory.
Source directories searched: /tmp/gcc/t/t/t/t:$cdir:$cwd
(gdb) start
Temporary breakpoint 1 at 0x40112e: file /cygdrive/d/Temp/cache/ccnRjjtS.i,
line
 11.
Starting program: /usr/libexec/gcc/i686-pc-cygwin/4.5.0/ecj1.exe java.java -g1
-
fbootclasspath=./:/usr/share/java/libgcj-4.5.0.jar -g1 -fsource=1.5
-ftarget=1.5
 -fzip-dependency java.zip -fzip-target java.jar
[New Thread 2040.0x1020]
warning: section .gnu_debuglink not found in /usr/bin/cygwin1.dbg
[New Thread 2040.0x1338]

Temporary breakpoint 1, main (argc=<value optimized out>,
    argv=<value optimized out>) at /cygdrive/d/Temp/cache/ccnRjjtS.i:11
11      /cygdrive/d/Temp/cache/ccnRjjtS.i: No such file or directory.
        in /cygdrive/d/Temp/cache/ccnRjjtS.i
(gdb) disp /i $eip
1: x/i $eip
=> 0x40112e <main+14>:  mov    0xc(%ebp),%eax
(gdb) b Calendar.java:500
Breakpoint 2 at 0x6c1b0ed6: file
../../../.././libjava/classpath/java/util/Calen
dar.java, line 500.
(gdb) c
Continuing.
[New Thread 2040.0x119c]
[New Thread 2040.0x1704]

Breakpoint 2, java.util.Calendar.<clinit>()void ()
    at ../../../.././libjava/classpath/java/util/Calendar.java:500
500         properties = new Properties();
1: x/i $eip
=> 0x6c1b0ed6 <java.util.Calendar.<clinit>()void+6>:
    movl   $0x6c5d0fe0,(%esp)
(gdb) n
503            
properties.load(Calendar.class.getResourceAsStream("weeks.proper
ties"));
1: x/i $eip
=> 0x6c1b0eec <java.util.Calendar.<clinit>()void+28>:   mov    0x6c5d5350,%eax
(gdb) n
500         properties = new Properties();
1: x/i $eip
=> 0x6c1b0ef1 <java.util.Calendar.<clinit>()void+33>:   mov    %ebx,0x6cabc75c
(gdb) n
503            
properties.load(Calendar.class.getResourceAsStream("weeks.proper
ties"));
1: x/i $eip
=> 0x6c1b0ef7 <java.util.Calendar.<clinit>()void+39>:
    movl   $0x6c5c84e0,(%esp)
(gdb) n
Exception in thread "main" java.lang.ExceptionInInitializerError
   at java.lang.Class.initializeClass(Unknown Source)
   at java.util.Calendar.getInstance(Unknown Source)
   at java.util.zip.ZipEntry.getDOSTime(Unknown Source)
   at java.util.zip.ZipOutputStream.putNextEntry(Unknown Source)
   at
org.eclipse.jdt.internal.compiler.batch.GCCMain.getZipOutput(GCCMain.java:
110)
   at
org.eclipse.jdt.internal.compiler.batch.GCCMain.configure(GCCMain.java:459
)
   at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1628)
   at org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(GCCMain.java:481)
   at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:498)
Caused by: java.lang.NullPointerException
   at java.io.InputStreamReader.read(Unknown Source)
   at java.io.BufferedReader.fill(Unknown Source)
   at java.io.BufferedReader.readLine(Unknown Source)
   at java.util.Properties.load(Unknown Source)
   at java.util.Properties.load(Unknown Source)
   at java.util.Calendar.<clinit>(Unknown Source)
   at java.lang.Class.initializeClass(Unknown Source)
   ...8 more

Program exited with code 01.
(gdb)

it seems that libgcj-bc is disabled except linux (libjava/configure.host)
but SUPPRESS_LIBGCJ_BC_TRUE is enabled because it is default. and problematic
switches "-fzip-dependency java.zip -fzip-target java.jar" try to load
weeks.properties resource. then it invokes url classloader and find resource in
libgcj-.jar so results exception.

i tried to compile with --disable-libgcj-bc, but it has undefined symbol with
namespace org.xml (showing that there is no choice but to use libgcj-bc)


-- 
           Summary: [4.5 regression] java.lang.ExceptionInInitializerError
                    in ecj1
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jojelino at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[jojelino at gmail dot com]

------- Comment #1 from jojelino at gmail dot com  2010-01-20 05:02 -------
linking executables with -Wl,--whole-archive libgcj-noncore.la libgcj.la
-Wl,--no-whole-archive solves this problem. excepts that it creates fatty
import symbol table approx. (28 megabyte). is there any workaround instead of
this naive method?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[jojelino at gmail dot com]

------- Comment #2 from jojelino at gmail dot com  2010-01-21 04:55 -------
Created an attachment (id=19671)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19671&action=view)
patch

now it summons gcj-noncore dll and resolves classes which should have been
resolved. i know it's not perfect. so i need your revision.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #3 from davek at gcc dot gnu dot org  2010-02-04 03:37 -------
(In reply to comment #2)
> Created an attachment (id=19671)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19671&action=view) [edit]
> patch
> 
> now it summons gcj-noncore dll and resolves classes which should have been
> resolved. i know it's not perfect. so i need your revision.

Thanks for this analysis, I think you're right, the classes provided in the
noncore dll need to be present and there aren't always linker dependencies to
bring them in.  I'll try and figure a way to do it automatically using static
dependencies.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot org
         AssignedTo|unassigned at gcc dot gnu   |davek at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-04 03:37:59
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #4 from davek at gcc dot gnu dot org  2010-02-05 17:44 -------
Created an attachment (id=19808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19808&action=view)
proposed fix

I'm going to bootstrap and test this patch, which adds a dummy static
dependency to pull in the noncore library everywhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #5 from davek at gcc dot gnu dot org  2010-02-20 00:40 -------
Created an attachment (id=19928)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19928&action=view)
patch respin

So, after much single-stepping in the debugger, and some discussion on the
mailing list:

http://gcc.gnu.org/ml/java/2010-02/msg00002.html
http://gcc.gnu.org/ml/java/2010-02/threads.html#00004

Here is the patch that I'm now testing.  It appeared to resolve the TestEarlyGC
failure after a quick rebuild in a dirty $objdir, but it needs a full
bootstrap/test cycle to be sure; results will be in tomorrow.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19808|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #6 from davek at gcc dot gnu dot org  2010-02-27 17:50 -------
Created an attachment (id=19977)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19977&action=view)
Alternative approach

This alternative approach attempts to place a circular dependency between the
two generated DLLs by linking into the core library a pseudo-import library
specially generated before the real -noncore import library is built.  Gonna
take it for a bootstrap and test cycle tonight.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #7 from davek at gcc dot gnu dot org  2010-03-20 20:02 -------
Raising priority P4 -> P3 and Cc'ing RM.

I didn't want to ask to block the release for a bug in a long-neglected
language on a secondary target before I was sure I'd be able to come up with a
fix in time, but now that I have a good fix that has been tested, addresses all
the comments raised in initial reviews, accepted upstream in the relevant
parts, and is just waiting approval, I'd like to make sure it goes in before
you branch; I see we're down to about half-a-dozen P1s now.

Final version of the patch posted at:

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00931.html


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
           Priority|P4                          |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-20 20:21 -------
Java is not release critical.  If it doesn't make 4.5.0 it can easily make
4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #9 from davek at gcc dot gnu dot org  2010-03-20 20:33 -------
Right you are.  I'll just have to hope it gets approved quickly while those
remaining P1s gradually tick away... :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #10 from davek at gcc dot gnu dot org  2010-03-21 19:25 -------
Recategorising; "target" narrowly wins out over "libjava".  Patch was approved
at http://gcc.gnu.org/ml/java-patches/2010-q1/msg00062.html


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|java                        |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #11 from davek at gcc dot gnu dot org  2010-03-21 19:34 -------
Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:34:19 2010
New Revision: 157604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157604
Log:
        PR target/42811 (prerequisite)
        * include/private/gc_priv.h (struct roots) [CYGWIN32]: Don't
        declare r_next member on Cygwin as on other windows hosts.
        (LOG_RT_SIZE) [CYGWIN32]: Don't define likewise.
        (RT_SIZE) [CYGWIN32]: Likewise.
        (struct _GC_arrays) [CYGWIN32]: Do declare _heap_bases[] member
        likewise.
        (GC_heap_bases) [CYGWIN32]: Do define likewise.
        (struct _SYSTEM_INFO) [CYGWIN32]: Do forward-declare likewise.
        (GC_sysinfo) [CYGWIN32]: Do declare extern likewise.
        (GC_n_heap_bases) [CYGWIN32]: Likewise.
        (GC_is_tmp_root) [CYGWIN32]: Do prototype likewise.
        * include/private/gcconfig.h (GC_win32_get_mem) [CYGWIN32]: Likewise.
        (GET_MEM) [CYGWIN32]: Do define likewise.
        * boehm-gc/ptr_chck.c (GC_is_visible) [CYGWIN32]: Do handle dynamic
        registration likewise.
        * boehm-gc/os_dep.c (GC_setpagesize) [CYGWIN32]: Do define likewise.
        (GC_no_win32_dlls) [CYGWIN32]: Define as constant false, unlike
        other windows hosts.
        (GC_sysinfo) [CYGWIN32]: Define as on other windows hosts.
        (GC_n_heap_bases) [CYGWIN32]: Likewise.
        (GLOBAL_ALLOC_TEST) [CYGWIN32]: Likewise.
        (GC_win32_get_mem) [CYGWIN32]: Likewise, but wrapping GC_unix_get_mem
        rather than GlobalAlloc/VirtualAlloc.
        (GC_win32_free_heap) [CYGWIN32]: Likewise, but wrapping free instead
        of GlobalFree (even though the function body is optimised away).
        * boehm-gc/mark_rts.c (add_roots_to_index) [CYGWIN32]: Define as on
        other windows hosts.
        (GC_add_roots_inner) [CYGWIN32]: Avoid overlapping or adjacent
        intervals likewise.
        (GC_clear_roots) [CYGWIN32]: Clear GC_root_index[] likewise.
        (GC_rebuild_root_index) [CYGWIN32]: Define as on other windows hosts.
        (GC_remove_tmp_roots) [CYGWIN32]: Call it likewise.
        (GC_remove_roots) [CYGWIN32]: Don't define, as on other windows hosts.
        (GC_is_tmp_root) [CYGWIN32]: Define, as on other windows hosts.
        (GC_cond_register_dynamic_libraries) [CYGWIN32]: Handle temporary
        roots and dynamic registration likewise.
        * boehm-gc/dyn_load.c (GC_has_static_roots) [CYGWIN32]: Define as on
        other windows hosts.
        (GC_register_has_static_roots_callback) [CYGWIN32]: Likewise.
        (GC_cond_add_roots) [CYGWIN32]: Likewise.
        (GC_register_main_static_data) [CYGWIN32]: Define to always return
        false, as on MSWINCE
        (HAVE_REGISTER_MAIN_STATIC_DATA) [CYGWIN32]: Define as on other
        windows hosts.
        (GC_warn_fb) [CYGWIN32]: Likewise.
        (GC_disallow_ignore_fb) [CYGWIN32]: Likewise.
        (GC_ignore_fb_mb) [CYGWIN32]: Likewise.
        (GC_ignore_fb) [CYGWIN32]: Likewise.
        (is_frame_buffer) [CYGWIN32]: Likewise.
        (GC_dump_meminfo) [CYGWIN32]: Likewise.
        (GC_wnt) [CYGWIN32]: Define to constant true.
        (GC_register_dynamic_libraries) [CYGWIN32]: Define as on other
        windows hosts.


Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/dyn_load.c
    trunk/boehm-gc/include/private/gc_priv.h
    trunk/boehm-gc/include/private/gcconfig.h
    trunk/boehm-gc/mark_rts.c
    trunk/boehm-gc/os_dep.c
    trunk/boehm-gc/ptr_chck.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #12 from davek at gcc dot gnu dot org  2010-03-21 19:37 -------
Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:36:49 2010
New Revision: 157605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157605
Log:
        PR target/42811 (prerequisite)
        * jvmti.cc (_Jv_GetJVMTIEnv): Avoid use of uninitialised memory.


Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/jvmti.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #13 from davek at gcc dot gnu dot org  2010-03-21 19:41 -------
Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:41:37 2010
New Revision: 157606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157606
Log:
        PR target/42811
        * libjava/configure.ac (DLLTOOL): Call AC_CHECK_TOOL.
        (libgcj_sublib_core_extra_deps): New host-dependent configure var.
        (LIBGCJ_SUBLIB_CORE_EXTRA_DEPS): AC_SUBST it.
        * libjava/configure.host (libgcj_sublib_core_extra_deps): Define
        appropriately on Cygwin and MinGW.
        (libgcj_sublib_core_extra_deps): Add libgcj-noncore-dummy import
        stub library on Cygwin and MinGW.
        * libjava/Makefile.am (LIBJAVA_CORE_EXTRA): Import AC_SUBST'd
        LIBGCJ_SUBLIB_CORE_EXTRA_DEPS if building sublibs, else define empty.
        (libgcj_la_DEPENDENCIES): Use it.
        (DLL_VERSION): New makefile macro.
        (libgcj-noncore-dummy.dll.a): New build rule for dummy import stub
        library.
        (libgcj_noncore_la_LIBADD): Trim superfluous convenience libs.
        (AM_MAKEFLAGS): Add DLLTOOL recursive propagation.
        * libjava/libgcj-noncore-dummy.def: New file.
        * libjava/Makefile.in: Regenerate.
        * libjava/include/Makefile.in: Likewise.
        * libjava/testsuite/Makefile.in: Likewise.
        * libjava/configure: Likewise.
        * libjava/gcj/Makefile.in: Likewise.


Added:
    trunk/libjava/libgcj-noncore-dummy.def
Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/Makefile.am
    trunk/libjava/Makefile.in
    trunk/libjava/configure
    trunk/libjava/configure.ac
    trunk/libjava/configure.host
    trunk/libjava/gcj/Makefile.in
    trunk/libjava/include/Makefile.in
    trunk/libjava/testsuite/Makefile.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #14 from davek at gcc dot gnu dot org  2010-03-21 19:42 -------
And another one bites the dust.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #15 from davek at gcc dot gnu dot org  2010-05-06 16:21 -------
Subject: Bug 42811

Author: davek
Date: Thu May  6 16:20:53 2010
New Revision: 159115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159115
Log:
        PR target/42811
        * tests/staticrootstest.c: New test source file.
        * tests/staticrootslib.c: New test library source file.
        * Makefile.am (test_ldadd): New variable.
        (gctest_LDADD): Use it.
        (TESTS): Add leaktest, middletest and staticrootstest.
        (check_PROGRAMS): Likewise.
        (leaktest_SOURCES): New libtool variable definition.
        (leaktest_LDADD): Likewise.
        (leaktest_LDFLAGS): Likewise.
        (leaktest_LINK): Likewise.
        (middletest_SOURCES): Likewise.
        (middletest_LDADD): Likewise.
        (middletest_LDFLAGS): Likewise.
        (middletest_LINK): Likewise.
        (staticrootstest_SOURCES): Likewise.
        (staticrootstest_LDADD): Likewise.
        (staticrootstest_LDFLAGS): Likewise.
        (staticrootstest_LINK): Likewise.
        (check_LTLIBRARIES): Likewise.
        (libstaticrootslib_la_SOURCES): Likewise.
        (libstaticrootslib_la_LIBADD): Likewise.
        (libstaticrootslib_la_LDFLAGS): Likewise.
        (libstaticrootslib_la_DEPENDENCIES): Likewise.
        * Makefile.in: Regenerate.


Added:
    trunk/boehm-gc/tests/staticrootslib.c
    trunk/boehm-gc/tests/staticrootstest.c
Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/Makefile.am
    trunk/boehm-gc/Makefile.in


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #16 from ubizjak at gmail dot com  2010-05-10 17:01 -------
On alphaev68-pc-linux-gnu, I'm getting:

make[4]: Entering directory
`/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5687484 collectable objects
Allocated 306 uncollectable objects
Allocated 3749022 atomic objects
Allocated 34440 stubborn objects
Finalized 6617/6617 objects - finalization is probably ok
Total number of bytes allocated is 228541040
Final heap size is 11345920 bytes
Collector appears to work
Completed 322 collections
PASS: gctest
Leaked composite object at 0x200002cdee0
(../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)

FAIL: leaktest
Final heap size is 131072
PASS: middletest
PASS: staticrootstest
===================
1 of 4 tests failed
===================
make[4]: *** [check-TESTS] Error 1

Is this failure something to worry about?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #17 from davek at gcc dot gnu dot org  2010-05-10 20:54 -------
(In reply to comment #16)
> On alphaev68-pc-linux-gnu, I'm getting:
> FAIL: leaktest

> 1 of 4 tests failed

> Is this failure something to worry about?

The honest answer is: I can't tell you.  These are test cases that come with
the boehm-gc itself, that have previously been disabled in the gcc import, now
I re-enabled them.  You won't be suffering from any problem that you didn't
already suffer from, in particular w.r.t the use of boehm-gc in libjava, but
while it's possible this is a false positive dependent on the precise details
of the platform, it's also possible this points to a real unfixed bug.  I don't
know of any way to tell without really getting down into debugging the
internals of the GC to see why it's complaining.

But, it's only a new failure because the test didn't used to be run before at
all.  You're definitely no worse off than you used to be; just now, you know
it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #18 from ubizjak at gmail dot com  2010-05-12 09:46 -------
FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
reason:

gmake[4]: Entering directory
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5705175 collectable objects
Allocated 306 uncollectable objects
Allocated 3750000 atomic objects
Allocated 34440 stubborn objects
Finalized 6679/6679 objects - finalization is probably ok
Total number of bytes allocated is 327875152
Final heap size is 22253568 bytes
Collector appears to work
Completed 384 collections
PASS: gctest
Leaked composite object at 0x2b5d6f749ef0
(../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)

PASS: leaktest
Final heap size is 131072
PASS: middletest
PASS: staticrootstest
==================
All 4 tests passed
==================


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #19 from davek at gcc dot gnu dot org  2010-05-12 16:48 -------
(In reply to comment #18)
> FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
> reason:

> Leaked composite object at 0x2b5d6f749ef0
> (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)
> 
> PASS: leaktest
> Final heap size is 131072

No, as far as I can see it's OK and that's a successful PASS.  The purpose of
the test is to leak some memory and verify that the GC can *detect* the leak.

As indeed it does in the other case as well, which now makes me suspect that
the alpha FAIL is probably a false negative.  The test code is rather old,
declares main as an implict int function, and doesn't have a return statement
in it.  That could easily end up returning some random register contents as an
exit status.  Do you have time to check if adding a "return 0;" at the end of
the main() function resolves the failure?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #20 from ubizjak at gmail dot com  2010-05-12 17:39 -------
(In reply to comment #19)

> As indeed it does in the other case as well, which now makes me suspect that
> the alpha FAIL is probably a false negative.  The test code is rather old,
> declares main as an implict int function, and doesn't have a return statement
> in it.  That could easily end up returning some random register contents as an
> exit status.  Do you have time to check if adding a "return 0;" at the end of
> the main() function resolves the failure?

Yeah, adding "return 0;" fixes the failure!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #21 from ubizjak at gmail dot com  2010-05-12 17:46 -------
Created an attachment (id=20652)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20652&action=view)
GC testsuite fixes

Patch that declares "int main" and adds "return 0;" to the tests.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #22 from ubizjak at gmail dot com  2010-05-12 17:50 -------
Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
-k check", so otherwise deadly trivial patch can't be fully tested.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

------- Comment #23 from davek at gcc dot gnu dot org  2010-05-12 22:20 -------
(In reply to comment #22)
> Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
> -k check", so otherwise deadly trivial patch can't be fully tested.
> 

Well I can't approve it but I think it's as close to "obvious" as anything
gets.  If you send it to libjava-patches (and cc the upstream list for
boehm-gc: <gc@napali.hpl.hp.com> - we're trying to avoid any divergence), I
can't imagine anyone would object.  Thanks for helping track this down :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

------- Comment #24 from ubizjak at gmail dot com  2010-05-12 22:51 -------
(In reply to comment #23)

> Well I can't approve it but I think it's as close to "obvious" as anything
> gets.  If you send it to libjava-patches (and cc the upstream list for
> boehm-gc: <gc@napali.hpl.hp.com> - we're trying to avoid any divergence), I
> can't imagine anyone would object.  Thanks for helping track this down :)

OK, patch sent and committed to SVN gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811