[aarch64-port-dev ] Bug of the month

[Andrew Haley]

This is some broken code that's a hangover from x86.  It causes SP to
contain a pointer not into the stack but to somewhere else altogether.
It only happens in the fairly rare case of a synchronized native
method that fails to acquire a lock.  Then we execute
complete_monitor_unlocking_C with a bogus SP, but as soon as we return
we restore SP to a sane value.  So, for a little while the native
stack is somewhere in the middle of the heap.  Ewww...

It's taken me about two days to find this because the symptoms seemed
to suggest a cause that was quite different.

A couple of things occur to me.  Firstly, the later in a project the
harder it is to find things like this.  Secondly, we have an amazingly
low defect rate when you consider just how much hand-carved assembly
code like this there is in the VM.

Andrew.



changeset:   4828:31390de29c4b
tag:         tip
user:        aph
date:        Mon Aug 12 17:49:56 2013 +0100
summary:     Delete bogus stack pointer adjustment

diff -r 64eb1c82b7fe -r 31390de29c4b src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
--- a/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp	Fri Aug 09 14:48:44 2013 +0100
+++ b/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp	Mon Aug 12 17:49:56 2013 +0100
@@ -2132,10 +2132,7 @@
     }

     __ lea(c_rarg1, Address(sp, lock_slot_offset * VMRegImpl::stack_slot_size));
-
     __ mov(c_rarg0, obj_reg);
-    __ mov(r20, sp); // remember sp
-    __ andr(sp, rscratch1, -16); // align stack as required by ABI

     // Save pending exception around call to VM (which contains an EXCEPTION_MARK)
     // NOTE that obj_reg == r19 currently
@@ -2143,7 +2140,7 @@
     __ str(zr, Address(rthread, in_bytes(Thread::pending_exception_offset())));

     rt_call(masm, CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_unlocking_C), 2, 0, 1);
-    __ mov(sp, r20); // restore sp
+
 #ifdef ASSERT
     {
       Label L;