Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test suite crashes on aarch64 #7602

Closed
vicuna opened this issue Aug 5, 2017 · 3 comments
Closed

Test suite crashes on aarch64 #7602

vicuna opened this issue Aug 5, 2017 · 3 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Aug 5, 2017

Original bug ID: 7602
Reporter: @rwmjones
Assigned to: @gasche
Status: resolved (set by @gasche on 2017-08-05T13:00:39Z)
Resolution: duplicate
Priority: normal
Severity: minor
Platform: aarch64
OS: Linux
Version: 4.05.0
Category: misc
Duplicate of: #7585

Bug description

I'm running the test suite on aarch64 with the very latest gcc, glibc and binutils:

gcc-7.1.1-7.fc27.1.aarch64
glibc-2.26-1.fc27.1.aarch64
binutils-2.29-6.fc27.aarch64

and it crashes in the test suite. For crash details, see below.

This worked before I upgraded those packages. I suspect either glibc or binutils are really to blame here and it may not be OCaml at all, so this is mainly a "heads up" that something is going on.

Reading symbols from /home/rjones/d/fedora-ocaml/testsuite/tests/lib-dynlink-native/main...done.
[New LWP 32284]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./main plugin.so plugin2.so plugin_thread.so'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffff8954d0e4 in camlPlugin__entry ()
from /home/rjones/d/fedora-ocaml/testsuite/tests/lib-dynlink-native/plugin.so
(gdb) bt
#0 0x0000ffff8954d0e4 in camlPlugin__entry ()
from /home/rjones/d/fedora-ocaml/testsuite/tests/lib-dynlink-native/plugin.so
#1 0x00000000004bfe3c in caml_start_program ()
#2 0x00000000004bab64 in caml_callback (
closure=closure@entry=281474943984712, arg=arg@entry=0) at callback.c:173
#3 0x00000000004bf8ac in caml_natdynlink_run (handle_v=,
symbol=) at natdynlink.c:141
#4 0x00000000004bfdac in caml_c_call ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Dump of assembler code for function camlPlugin__entry:
0x0000ffff8954d0d0 <+0>: sub sp, sp, #0x20
0x0000ffff8954d0d4 <+4>: str x30, [sp, #24]
0x0000ffff8954d0d8 <+8>: adrp x0, 0xffff8956c000
0x0000ffff8954d0dc <+12>: add x0, x0, #0x2d8
0x0000ffff8954d0e0 <+16>: adrp x16, 0xffff8954d000 <__do_global_dtors_aux+24>
=> 0x0000ffff8954d0e4 <+20>: str x0, [x16, #576]
0x0000ffff8954d0e8 <+24>: adrp x1, 0xffff8956c000
0x0000ffff8954d0ec <+28>: add x1, x1, #0x2c0
0x0000ffff8954d0f0 <+32>: adrp x16, 0xffff8954d000 <__do_global_dtors_aux+24>

(gdb) info registers
x0 0xffff8956c2d8 281472985907928
x1 0xfffffe0ca418 281474943984664
x2 0x19958c20 429231136
x3 0x198fb010 428847120
x4 0x1 1
x5 0x0 0
x6 0x0 0
x7 0xffff90c144a1 281473110328481
x8 0xfffffe0ca520 281474943984928
x9 0x4bfe9c 4980380
x10 0x0 0
x11 0x19958128 429228328
x12 0xffff8954c2c0 281472985776832
x13 0x0 0
x14 0x17 23
x15 0xffff8954d0d0 281472985780432
x16 0xffff8954d000 281472985780224
x17 0x559000 5607424
x18 0x0 0
x19 0x199581b0 429228464
x20 0xffff89be2468 281472992683112
x21 0x557000 5599232
x22 0x0 0
x23 0xffff8954d1e0 281472985780704
x24 0xffff8954d038 281472985780280
x25 0xffff89be2ab8 281472992684728
x26 0xfffffe0ca2e0 281474943984352
x27 0xffff89be1fd0 281472992681936
x28 0xffff899f2000 281472990650368
x29 0xfffffe0ca310 281474943984400
x30 0x4bfe3c 4980284
sp 0xfffffe0ca2c0 0xfffffe0ca2c0
pc 0xffff8954d0e4 0xffff8954d0e4 <camlPlugin__entry+20>
cpsr 0x80000000 [ EL=0 N ]
fpsr 0x0 0
fpcr 0x0 0

Steps to reproduce

Compile ocaml and run the test suite from the build directory in the normal way.

@vicuna
Copy link
Author

vicuna commented Aug 5, 2017

Comment author: @rwmjones

I should say that everything works fine on all other architectures that we test (x86_64, ppc64, ppc64le). That's even with the latest binutils etc.

@vicuna
Copy link
Author

vicuna commented Aug 5, 2017

Comment author: @gasche

Thanks for the detailed crash report. I believe (please complain if this is not the case!) that this is the same issue as #7585, in which there is already ample discussion. See also a proposed patch in discussion:

#1268

@vicuna vicuna closed this as completed Aug 5, 2017
@vicuna
Copy link
Author

vicuna commented Sep 13, 2017

Comment author: @xavierleroy

Fixed (we think) by this pull request: #1330

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants