512563 - Mops test generates datatype misalignment exceptions on ARM when interpreted

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect, P3)

Description

[Tom Donovan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.39 Safari/530.5
Build Identifier: avmplus shell 1.4 build cyclone

Alignment exception on ARM when interpreted.  
Similar to bug 508847, which fixed this for nanojit.

Reproducible: Always

Steps to Reproduce:
1. build tamarin-redux ARM/Linux. 
2. python runtests.py -v --vmargs=-Dinterp mops 

Actual Results:  
Tamarin tests started: 2009-08-25 18:25:03.698201
executing: file "/root/tamarin-redux/objdir/shell/avmshell"
determineConfig: /root/tamarin-redux/objdir/shell/avmshell: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

executing: /root/tamarin-redux/objdir/shell/avmshell
Writing results to 2009-08-25.12.html
current configuration: x86-lnx-tvm-release-Dinterp
Executing 1 tests against vm: /root/tamarin-redux/objdir/shell/avmshell
executing: /root/tamarin-redux/objdir/shell/avmshell -Dinterp mops/mops.abc_ mops/mops.abc
Alignment trap: not handling instruction edd37a00 at [<000d9d54>]
Unhandled fault: alignment exception (0x001) at 0x40456001
0.1 running mops/mops.as mops/mops.abc_
   unexpected exit code expected:0 actual:-4 FAILED!
   captured output:
   FAILED passes:0 fails:1 unexpected passes: 0 expected failures: 0

FAILURES:
  mops/mops.abc : unexpected exit code expected:0 actual:-4 FAILED!
  mops/mops.abc : captured output:

test run FAILED!
Tests complete at 2009-08-25 18:25:04.237569
Start Date: 2009-08-25 18:25:03.698201
End Date  : 2009-08-25 18:25:04.237569
Test Time : 0:00:00.539368
passes               : 0
failures             : 1
Results were written to 2009-08-25.12.html

Expected Results:  
Tamarin tests started: 2009-08-25 18:27:08.083394
executing: file "/root/tamarin-redux/objdir/shell/avmshell"
determineConfig: /root/tamarin-redux/objdir/shell/avmshell: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

executing: /root/tamarin-redux/objdir/shell/avmshell
Writing results to 2009-08-25.13.html
current configuration: x86-lnx-tvm-release-Djitordie
Executing 1 tests against vm: /root/tamarin-redux/objdir/shell/avmshell
executing: /root/tamarin-redux/objdir/shell/avmshell -Djitordie mops/mops.abc_ mops/mops.abc
0.1 running mops/mops.as mops/mops.abc_
domainClass == null = false PASSED!
...
Read/write double scratch = true PASSED!
metric mops 37499
   PASSED passes:56 fails:0 unexpected passes: 0 expected failures: 0

test run PASSED!
Tests complete at 2009-08-25 18:27:46.374806
Start Date: 2009-08-25 18:27:08.083394
End Date  : 2009-08-25 18:27:46.374806
Test Time : 0:00:38.291412
passes               : 56
failures             : 0
Results were written to 2009-08-25.13.html

Comment 1

[Lars T Hansen]

Not currently reproducible on the beagleboard (Ubuntu, 2.6.16).

Comment 2

[Lars T Hansen]

(In reply to comment #1)
> Not currently reproducible on the beagleboard (Ubuntu, 2.6.16).

That said, it's pretty clear that the interpreter code does not guard against unaligned accesses for the MOPS.

Comment 3

[Brent Baker]

Is it possible that this was addressed in bug 508847?

Comment 4

[Lars T Hansen]

(In reply to comment #3)
> Is it possible that this was addressed in bug 508847?

I don't think so - the interpreter doesn't use the routines on MethodEnv but open-codes the functionality and its implementations don't handle alignment restrictions.  It's possible we should just change that, if we can.

Comment 5

[Tom Donovan]

Confirm that I can no longer reproduce this problem on ARM with the current tamarin-central or -redux code:  Debian 5 (kernel 2.6.18) or Ubuntu 9 (kernel 2.6.28).

I logged this bug after bug 508847 got fixed for JIT on 8/14/2009.  After bug 508847 was fixed, alignment errors occurred only when interpreting byte code.

Comment 6

[Lars T Hansen]

Foo.  The CPU on the beagleboard supports unaligned data accesses; I have verified this two different ways (with MOPS bytecodes and with C++ code).

Comment 7

[Lars T Hansen]

(In reply to comment #6)
> The CPU on the beagleboard supports unaligned data accesses

... as does every Apple PPC machine, I believe.  Certainly my old G3 PowerBook does (verified by C++ code).

That fact may be of some interest for tuning if it turns out that the one unaligned access is faster than a the several loads and bit operations that simulate it.

Comment 8

[Lars T Hansen]

Attachment: Patch

If AVMPLUS_UNALIGNED_ACCESS is not enabled then call the methods on MethodEnv.  We assume that those will be correct (they look correct).  I have tested this on PPC, which we currently compile without enabling unaligned access, so I believe this is correct even if I have not been able to provoke a crash on a platform and see that this patch fixes it.

Comment 9

[Lars T Hansen]

redux changeset:   2710:7226726e4124

Comment 10

[Tom Donovan]

Reverted to the 8/25/2009 tamarin-redux source and reproduced this with gcc 4.3.2 & Glibc 2.7 on Debian5-ARM (but, curiously - I could not reproduce it with gcc 4.3.3 & GLibc 2.9 on Ubuntu9-ARM...)

Applied the patch from comment #8 and no longer get unaligned access SIGILL -- so it seems this is a correct fix.

Note that the unaligned instruction was a 'flds' from an odd memory address: 0x40457001.  I don't think "supports unaligned data accesses" really goes this far!   FYI - stack & registers at crash (not a debug build):

==============================================
(gdb) info program
        Using the running image of child Thread 0x4001f440 (LWP 1939).
Program stopped at 0xd9d58.
It stopped with signal SIGILL, Illegal instruction.
(gdb) where
#0  0x000d9d58 in avmplus::interpBoxed ()
#1  0x00085ad8 in avmplus::Toplevel::op_call ()
#2  0x000dc56c in avmplus::interpBoxed ()
#3  0x000874cc in avmplus::Toplevel::callproperty ()
#4  0x000daaa0 in avmplus::interpBoxed ()
#5  0x000ddc00 in avmplus::interpGPR ()

(gdb) info register all
r0             0x40319418       1076991000
r1             0x40319418       1076991000
r2             0x8      8
r3             0x40457001       1078292481
r4             0x1      1
r5             0x2      2


0x000d9d38 :  ldr     r0, [r11, #-468]
0x000d9d3c :  bl      0x6f988 <avmplus::MethodEnv::mopRangeCheckFailed() const>
0x000d9d40 :  ldr     lr, [r11, #-400]
0x000d9d44 :  ldr     r0, [r11, #-452]
0x000d9d48 :  mov     r7, r6
0x000d9d4c :  ldr     r3, [lr, #16]
0x000d9d50 :  add     r3, r3, r4
0x000d9d54 :  flds    s15, [r3]   <<<<<<<<<  CRASHED HERE <<<<<<<<<
0x000d9d58 :  fcvtds  d16, s15
0x000d9d5c :  vmov    r2, r3, d16
0x000d9d60 :  bl      0x5bf4c <avmplus::AvmCore::doubleToAtom(double)>
0x000d9d64 :  ldr     r8, [r11, #-416]
0x000d9d68 :  str     r0, [r8]
0x000d9d6c :  b       0xd7db8 <avmplus::interpBoxed(avmplus::MethodEnv*, int, int*, avmplus::MethodSignature const*)+2132>
0x000d9d70 :  ldr     r1, [r11, #-416]
0x000d9d74 :  ldr     r0, [r1]

Comment 11

[Steven Johnson]

(In reply to comment #7)
> (In reply to comment #6)
> > The CPU on the beagleboard supports unaligned data accesses
> ... as does every Apple PPC machine, I believe.  Certainly my old G3 PowerBook
> does (verified by C++ code).
> That fact may be of some interest for tuning if it turns out that the one
> unaligned access is faster than a the several loads and bit operations that
> simulate it.

Indeed. It's definitely worth investigating to find out. I'd be surprised if it's not at least as fast, but who knows...

Comment 12

[Lars T Hansen]

(In reply to comment #10)
> Reverted to the 8/25/2009 tamarin-redux source and reproduced this with gcc
> 4.3.2 & Glibc 2.7 on Debian5-ARM (but, curiously - I could not reproduce it
> with gcc 4.3.3 & GLibc 2.9 on Ubuntu9-ARM...)
> 
> Applied the patch from comment #8 and no longer get unaligned access SIGILL --
> so it seems this is a correct fix.

Thank you, the effort is greatly appreciated.

> Note that the unaligned instruction was a 'flds' from an odd memory address:
> 0x40457001.  I don't think "supports unaligned data accesses" really goes this
> far!

Good data point.  I will try to augment our test suite accordingly.

Comment 13

[Brent Baker]

Removing in-testsuite from this bug and will track it via bug# 549296

Comment 14

[Brent Baker]

verified fix in tr-argo build 3840:eebec82bfb22, bug 549296 has a patch to add this testcase into a deep phase pass