Status fields:
creation_ts: | 2009-05-29 02:06 |
---|---|
component: | native |
version: | 0.99.4 |
rep_platform: | x86_64 |
op_sys: | Linux |
bug_status: | RESOLVED |
resolution: | FIXED |
reporter: | gnu_andrew@member.fsf.org |
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b02508 in GC_find_limit_with_bound (p=0x7ffff7dd2ab8 "", up=0, bound=0x0) at os_dep.c:928 928 GC_noop1((word)(*result)); Missing separate debuginfos, use: debuginfo-install glibc-2.9-3.x86_64 zlib-1.2.3-18.fc9.x86_64 (gdb) bt #0 0x00007ffff7b02508 in GC_find_limit_with_bound (p=0x7ffff7dd2ab8 "", up=0, bound=0x0) at os_dep.c:928 #1 0x00007ffff7b025d9 in GC_init_linux_data_start () at os_dep.c:466 #2 0x00007ffff7b0fdf8 in GC_init_inner () at misc.c:624 #3 0x00007ffff7b01537 in gc_init (heapmaxsize=134217728, heapstartsize=2097152) at boehm.c:101 #4 0x00007ffff7b31bfb in vm_create (vm_args=0x7fffffffae70) at vm.c:1395 #5 0x00007ffff7b32282 in vm_createjvm (p_vm=0x7fffffffae98, p_env=0x7fffffffae90, vm_args=0x7fffffffae70) at vm.c:727 #6 0x00007ffff7b15047 in JNI_CreateJavaVM (p_vm=0x7fffffffae98, p_env=0x7fffffffae90, vm_args=0x7fffffffae70) at jni.c:4368 #7 0x00007ffff7dd8e2f in InitializeJVM () at ../../../src/share/bin/java.c:1107 #8 JavaMain (_args=<value optimized out>) at ../../../src/share/bin/java.c:369 #9 0x00007ffff7dd9bb1 in ContinueInNewThread (ifn=0x7fffffffe0d0, argc=1, argv=0x601138, jarfile=0x0, classname=0x0, ret=<value optimized out>) at ../../../src/share/bin/java.c:1893 #10 0x00007ffff7dda653 in JLI_Launch (argc=1, argv=0x601138, jargc=1, jargv=0x0, appclassc=1, appclassv=0x0, fullversion=0x40086c "1.7.0_0-icedtea-b59", dotversion=0x400868 "1.7", pname=0x400880 "java", lname=0x400880 "java", javaargs=0 '\0', cpwildcard=1 '\001', javaw=<value optimized out>, ergo=0) at ../../../src/share/bin/java.c:327 It previously worked with 1.9 (based on b50).
The stacktrace shown here is not the one causing the problem. This one seems to be intentional and is caught by Boehm GC.
The real problem is this: While in java.lang.ClassLoader.<clinit>, CACAO gets to a point [1] where it tries to resolve the method "java.lang.Object.hashCode". This in turn causes it to call ClassLoader.findNative which accesses the not-yet initialized systemNativeLibraries which gives us a nice NullPointerException. [1] via java.util.Collections$SetFromMap.add(Ljava/lang/Object;)Z -> java.util.Collectio ns$SynchronizedMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; -> java.util.WeakHashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
Created an attachment (id=61) experimental patch This patch (against hg default) fixes it. Currently, CACAO looks at [...] for a function (in this order): 1. shared libraries (dlsym) 2. java.lang.ClassLoader.findNative 3. internal (registered) methods The patch just changes the order of this lookup and consults internal methods first. I really don't know why the original order was chosen or why it worked in the past. twisti, can you comment on this?
It's actually fairly easy to guess what broke it - http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/45ff1a9d4edb I have not verified this but the new HashTable stuff seems to be what tripped up CACAO.
Yes, internal methods should be resolved first. This is a long standing issue I never came around to fix.
Created an attachment (id=62) experimental patch transplanted for cacao 0.99.x release branch I did a rewrite of Stefan Rings experimental patch from cpp to c so that it could be applied on the cacao 0.99.x release branch. Using this patch I have been able to compile and run Icedtea7+cacao and Icedtea6+cacao using cacao 0.99.4 on IA32.
Thanks Xerces. I changed my patch slightly and just committed it. http://mips.complang.tuwien.ac.at/hg/cacao/rev/d5ecceaf8b86
Thank you Stefan! To clarify: I have built icedtea-ecj icedtea7 + cacao using the last patch. and And full icedtea6 + cacao build. When building a full icedtea7 build with cacao i now hit this new error: Should i open a new bug for this build error? # Running javac: /home/xerxes/icedtea7/bootstrap/jdk1.6.0/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/home/xerxes/icedtea7/openjdk/build/linux-i586/langtools/dist/bootstra p/lib/javac.jar -jar /home/xerxes/icedtea7/openjdk/build/linux-i586/langtools/dist/bootstrap/lib/javac.jar -g -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/home/xerxes/icedtea7/openjdk/build/linux-i586/classes -sourcepath /home/xerxes/icedtea7/openjdk/build/linux-i586/gensrc:../../../src/solaris/classes:../.. /../src/share/classes -d /home/xerxes/icedtea7/openjdk/build/linux-i586/classes @/home/xerxes/icedtea7/openjdk/build/linux-i586/tmp/java/java.lang/java/.classes.list.fi ltered Unknown -XX option: -XX:-PrintVMOptions Unknown -XX option: -XX:+UnlockDiagnosticVMOptions Unknown -XX option: -XX:-LogVMOutput /home/xerxes/icedtea7/openjdk/build/linux-i586/gensrc/java/nio/DirectByteBuffer.java:549 : <identifier> expected Unknown -XX option: -XX:-PrintVMOptions ^ /home/xerxes/icedtea7/openjdk/build/linux-i586/gensrc/java/nio/DirectByteBuffer.java:549 : ';' expected Unknown -XX option: -XX:-PrintVMOptions ^ ... /home/xerxes/icedtea7/openjdk/build/linux-i586/gensrc/java/nio/charset/CharsetDecoder.ja va:973: class, interface, or enum expected Unknown -XX option: -XX:-PrintVMOptions ^ /home/xerxes/icedtea7/openjdk/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.ja va:973: class, interface, or enum expected Unknown -XX option: -XX:-PrintVMOptions ^ 94 errors make[6]: *** [.compile.classlist] Error 1 make[6]: Leaving directory `/home/xerxes/icedtea7/openjdk/jdk/make/java/java' make[5]: *** [all] Error 1 make[5]: Leaving directory `/home/xerxes/icedtea7/openjdk/jdk/make/java' make[4]: *** [all] Error 1 make[4]: Leaving directory `/home/xerxes/icedtea7/openjdk/jdk/make' make[3]: *** [jdk-build] Error 2 make[3]: Leaving directory `/home/xerxes/icedtea7/openjdk' make[2]: *** [build_product_image] Error 2 make[2]: Leaving directory `/home/xerxes/icedtea7/openjdk' make[1]: *** [jdk_only] Fel 2 make[1]: Lämnar katalogen "/home/xerxes/icedtea7/openjdk" make: *** [stamps/icedtea.stamp] Fel 2 xerxes@labbserver:~/icedtea7$ /home/xerxes/icedtea7/bootstrap/jdk1.6.0/bin/java -version java version "1.7.0_0-icedtea" IcedTea Runtime Environment (1.10-pre-r9a8c3c90bdb2) (build 1.7.0_0-icedtea-b59) CACAO (build 0.99.4, compiled mode) xerxes@labbserver:~/icedtea7$ Obviously the full openjdk build passes some -XX options that are not supported when running with cacao.
Created an attachment (id=63) cacao-0.99.x-pr128.patch (In reply to comment #7) > Thanks Xerces. I changed my patch slightly and just committed it. > > http://mips.complang.tuwien.ac.at/hg/cacao/rev/d5ecceaf8b86 > I have attached a new 0.99.x patch that includes the slight changes of your commit. cheers Xerxes
Created an attachment (id=64) xxoption-warning.patch
Created an attachment (id=65) native-resolve.patch I just used these two patches to successfully do a clean build of icedtea (7) 1.10 They are also committed as: http://mips.complang.tuwien.ac.at/hg/cacao/rev/5fdb98095047 http://mips.complang.tuwien.ac.at/hg/cacao/rev/8e8a38453f6c
date: | 2009-05-31 17:37 |
---|---|
desc: | experimental patch |
type: | text/plain |
download: | patch.txt |
date: | 2009-06-02 14:32 |
---|---|
desc: | experimental patch transplanted for cacao 0.99.x release branch |
type: | text/plain |
download: | cacao0.99.x_pr128.patch |
date: | 2009-06-03 11:41 |
---|---|
desc: | cacao-0.99.x-pr128.patch |
type: | text/plain |
download: | 3jun-cacao-0.99.x-pr128.patch |
date: | 2009-06-03 12:07 |
---|---|
desc: | xxoption-warning.patch |
type: | text/plain |
download: | xxoption-warning.patch |
date: | 2009-06-03 12:09 |
---|---|
desc: | native-resolve.patch |
type: | text/plain |
download: | native-resolve.patch |