ResourceBundle on svn head has a regression. It doesn't find the correct class loader from the stack. I'll attach a test case. To see the bug: cd Fail gij -cp main.jar F
Created attachment 13024 [details] bug tar
I can't reproduce this with trunk or any of the Red Hat test builds. zebedee:/tmp/Fail $ gij -cp main.jar F class Z java.util.PropertyResourceBundle@3169d8b5 zebedee:/tmp/Fail $ gij --version java version "1.5.0" gij (GNU libgcj) version 4.1.1 20070202 (Red Hat 4.1.1-55) zebedee:/tmp/Fail $ ~/gcc/trunk/install/bin/gij -cp main.jar F class Z java.util.PropertyResourceBundle@319b98f5 zebedee:/tmp/Fail $ ~/gcc/trunk/install/bin/gij --version java version "1.5.0" gij (GNU libgcj) version 4.3.0 20070208 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Definitely fails with trunk on x86.
So far the bug seems to be that we reach the "CALLER_OF_CALLER" state in stackwalker_trace_fn with ResourceBundle as the class. There seems to be one more frame on the stack than this code expects.
Created attachment 13028 [details] first patch This patch fixes the problem for me. In my run, the GetStackWalkerCallingClass call in getCallingClass returns ResourceBundle -- but what we want it ResourceBundle's caller. This is pretty awful though. I think perhaps we need a new API in _Jv_StackTrace for this case. Also I think there must be something here I am missing, since I don't see how this code could work on any platform.
Definitely a 32-bit only issue: zorro:/tmp/Fail $ ~/gcc/trunk/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/gij -cp main.jar F class Z java.util.PropertyResourceBundle@317b08f5 zorro:/tmp/Fail $ ~/gcc/trunk/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/32/libjava/gij -cp main.jar F class Z Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass(natClass.cc:767) at java.lang.Class.newInstance(Class.h:733) at F.main(F.java:9) Caused by: java.util.MissingResourceException: Bundle org/test not found for locale en_US by classloader gnu.gcj.runtime.SystemClassLoader{urls=[file:main.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.util.ResourceBundle.getBundle(ResourceBundle.java:410) at java.util.ResourceBundle.getBundle(ResourceBundle.java:231) at Z.<clinit>(Z.java:6) at java.lang.Class.initializeClass(natClass.cc:755) ...2 more
Created attachment 13029 [details] It's a patch! This is the correct patch. The key here is that it is never correct for one VMStackWalker method to call another, becasue that introduces another level of nesting.
Subject: Bug 30742 Author: aph Date: Sat Feb 10 14:22:54 2007 New Revision: 121798 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121798 Log: 2007-02-10 Andrew Haley <aph@redhat.com> PR java/30742 * gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): New. (getCallingClass): Call GET_CALLING_CLASS. (getCallingClassLoader): Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/classpath/natVMStackWalker.cc
Subject: Bug 30742 Author: aph Date: Sat Feb 10 14:36:28 2007 New Revision: 121799 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121799 Log: 2007-02-10 Andrew Haley <aph@redhat.com> PR java/30742 * gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): New. (getCallingClass): Call GET_CALLING_CLASS. (getCallingClassLoader): Likewise. Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/gnu/classpath/natVMStackWalker.cc
Fix checked in.