SIGSEGV in boostrap classloader on x86-64 about jato

[penberg]

I see the exact same problem with GCC 4.6.3 when trying to launch JRuby which means GCC version doesn't really make a difference.

[penberg@tux jruby-1.7.3]$ jato -jar lib/jruby.jar  -v
[main] SIGSEGV at RIP 06337c20 while accessing memory address 7fff6cf75c08.
[main] Registers:
[main]  rsp: 00007fff66e4ec08
[main]  rax: 000000004242ad75   rbx: 0000000000008000   rcx: 0000000000008000
[main]  rdx: 0000000000000000   rsi: 0000000006127000   rdi: 0000000001711b60
[main]  rbp: 00007fff66e4edf0   r8:  0000000000008000   r9:  0000000006127000
[main]  r10: 0000000000000000   r11: 0000003e8ee8b508   r12: 0000000000008000
[main]  r13: 0000000006340c80   r14: 0000000000000002   r15: 0000000001711b60
[main] Stack:
[main] 000000004242ad60 0000000001711b60 0000000001711b60 0000000006127000 
[main] 0000000000000000 0000000000008000 0000000000008000 00007fff66e4ec80 
[main] 0000000000008000 0000000000000000 0000000006127000 0000000001711b60 
[main] Code: 00 00 00 e1 00 00 00 00 00 00 00 70 56 b4 05 00 00 00 00 50 09 34 06 00 00 00 00 88 56 b4 05 00 00 00 00 02 00 00 00 00 00 00 00 <80> 0c 34 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[main] Native and Java stack trace:
[main]  [<06337c20>] native     : signal_bh_trampoline+5eea808 (arch/x86/signal-bh.S:126)
[main]  [<4242a0c8>] jit        : java/util/zip/Inflater.inflate(Inflater.java:322)
[main]  [<424283ec>] jit        : java/util/zip/InflaterInputStream.read(InflaterInputStream.java:196)
[main]  [<422f06d3>] jit        : java/io/InputStreamReader.read(InputStreamReader.java:393)
[main]  [<422ee74a>] jit        : java/io/BufferedReader.fill(BufferedReader.java:370)
[main]  [<422ebd1b>] jit        : java/io/BufferedReader.readLine(BufferedReader.java:469)
[main]  [<42338993>] jit        : gnu/java/util/jar/JarUtils.read_attributes(JarUtils.java:194)
[main]  [<42338305>] jit        : gnu/java/util/jar/JarUtils.readMainSection(JarUtils.java:140)
[main]  [<423358b0>] jit        : gnu/java/util/jar/JarUtils.readMFManifest(JarUtils.java:101)
[main]  [<422a0bd1>] jit        : java/util/jar/Manifest.read(Manifest.java:162)
[main]  [<4229d76f>] jit        : java/util/jar/Manifest.<init>(Manifest.java:89)
[main]  [<42295e3f>] jit        : java/util/jar/JarFile.readManifest(JarFile.java:303)
[main]  [<42293ee8>] jit        : java/util/jar/JarFile.<init>(JarFile.java:268)
[main]  [<4223b713>] jit        : gnu/java/net/protocol/jar/Connection$JarFileCache.get(Connection.java:99)
[main]  [<422383a2>] jit        : gnu/java/net/protocol/jar/Connection.connect(Connection.java:141)
[main]  [<4240cf5b>] jit        : gnu/java/net/protocol/jar/Connection.getJarFile(Connection.java:170)
[main]  [<42408965>] jit        : gnu/java/net/loader/JarURLLoader.initialize(JarURLLoader.java:85)
[main]  [<42400382>] jit        : gnu/java/net/loader/JarURLLoader.<init>(JarURLLoader.java:76)
[main]  [<423fc36b>] jit        : java/net/URLClassLoader.addURLImpl(URLClassLoader.java:387)
[main]  [<423f3124>] jit        : java/net/URLClassLoader.addURLs(URLClassLoader.java:418)
[main]  [<423f1b81>] jit        : java/net/URLClassLoader.<init>(URLClassLoader.java:217)
[main]  [<423f11c4>] jit        : java/lang/ClassLoader$1.<init>(ClassLoader.java:1099)
[main]  [<423f0548>] jit        : java/lang/ClassLoader.createSystemClassLoader(ClassLoader.java:1099)
[main]  [<423e2904>] jit        : java/lang/ClassLoader.defaultGetSystemClassLoader(ClassLoader.java:1084)
[main]  [<423e2300>] jit        : java/lang/VMClassLoader.getSystemClassLoader(VMClassLoader.java:379)
[main]  [<41d9a833>] jit        : java/lang/ClassLoader$StaticData.<clinit>(ClassLoader.java:154)
[main]  [<0041a071>] native     : vm_class_init+1d2 (/home/penberg/jato/vm/class.c:748)
[main]  [<00457d06>] native     : vm_class_ensure_init+527f8 (/home/penberg/jato/include/vm/class.h:126)
[main]  [<41d97a63>] jit        : java/lang/ClassLoader.getSystemClassLoader(ClassLoader.java:799)
[main]  [<0042c7a4>] native     : native_call_gp+1b4 (/home/penberg/jato/arch/x86/call.c:204)
[main]  [<0042c833>] native     : native_call+66 (/home/penberg/jato/arch/x86/call.c:253)
[main]  [<00417b93>] native     : call_method_a+3d (/home/penberg/jato/vm/call.c:54)
[main]  [<00417ce4>] native     : vm_call_method_v+131 (/home/penberg/jato/vm/call.c:71)
[main]  [<0041ba00>] native     : vm_call_method_object+873a (/home/penberg/jato/include/vm/call.h:81)
[main]  [<0041ce29>] native     : get_system_class_loader+31 (/home/penberg/jato/vm/classloader.c:770)
[main]  [<00406698>] native     : do_main_class+1f (/home/penberg/jato/jato.c:1004)
[main]  [<004068a5>] native     : do_jar_file+8 (/home/penberg/jato/jato.c:1068)
[main]  [<00406c51>] native     : main+219 (/home/penberg/jato/jato.c:1218)
[main]  [<3e8ee2169c>] native     : signal_bh_trampoline+3e8e9d4284 (arch/x86/signal-bh.S:126)
Aborted

I see the same problem with -Os and -O3 optimization levels which points to stack alignment issues still...

[penberg]

Launching JRuby with -Xdebug:stack yields the following error:

[penberg@tux jruby-1.7.3]$ jato -Xdebug:stack -jar lib/jruby.jar  -v
Error: stack is 8 bytes misaligned when entering function:

  gnu/java/net/loader/JarURLLoader.<init>(Ljava/net/URLClassLoader;Lgnu/java/net/loader/URLStreamHandlerCache;Ljava/net/URLStreamHandlerFactory;Ljava/net/URL;Ljava/net/URL;)V.

which has 0 arguments passed on the stack.
Aborted

[penberg]

Looking at the stack trace and the stack alignment check error, we first enter addURLImpl, then ClassNotFoundException is throw from Class.forName after which we invoke JarURLLoader constructor which now has wrong stack alignment.

This seems to point to exception handling not cleaning up the stack properly somewhere on x86-64.

[penberg]

It turns out that with GCC 4.7.2 no exception is throw. The last invoked method is decode():

[main] trace invoke: java/util/zip/Inflater.decode()Z

which suggest that the generated code for that method is broken on x86-64.

[penberg]

Evidence points to TABLESWITCH miscompilation on x86-64.

On 32-bit, we have this:

[main]   0xa745be57:   81 ef 00 00 00 00          sub    $0x0,%edi
[main]   0xa745be5d:   be 28 a1 7a 09             mov    $0x97aa128,%esi
[main]   0xa745be62:   ff 24 be                   jmp    *(%esi,%edi,4)

But on 64-bit, we have this:

[main]   0x424b1fbb:   41 81 ee 00 00 00 00       sub    $0x0,%r14d
[main]   0x424b1fc2:   49 bd b0 de f9 05 00 00 00 00    movabs $0x5f9deb0,%r13
[main]   0x424b1fcc:   43 ff 24 f5 50 2b f6 05    jmpq   *0x5f62b50(,%r14,8)

As the instruction selectors look pretty much identical, it's likely that INSN_JMP_MEMINDEX encoding has a bug on 64-bit.