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

SEGV when running 'MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S02-types/num.rakudo.moar' #791

Closed
dogbert17 opened this issue Jan 30, 2018 · 4 comments

Comments

@dogbert17
Copy link
Contributor

dogbert17 commented Jan 30, 2018

Fails on both 32- and 64-bit Linux VM's

dilbert@Linux-Mint18 ~/repos/rakudo $ ./perl6 -v
This is Rakudo version 2018.01-60-g2c36ab2 built on MoarVM version 2018.01-49-g783a4f0
implementing Perl 6.c.

dilbert@Linux-Mint18 ~/repos/rakudo $ MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6-gdb-m t/spec/S02-types/num.rakudo.moar
================================================================================================
This is Rakudo Perl 6 running in the GNU debugger, which often allows the user to generate useful back-
traces to debug or report issues in Rakudo, the MoarVM backend or the currently running code.

This Rakudo version is 2018.01.58.g.58.de.239 built on MoarVM version 2018.01.49.g.783.a.4.f.0,
running on linuxmint (18.3.Sylvia) / linux (4.10.0.38.generic)

Type `bt full` to generate a backtrace if applicable, type `q` to quit or `help` for help.
------------------------------------------------------------------------------------------------
Reading symbols from /home/dilbert/repos/rakudo/install/bin/moar...done.
Starting program: /home/dilbert/repos/rakudo/install/bin/moar --execname=./perl6-gdb-m --libpath=. --libpath=blib --libpath=/home/dilbert/repos/rakudo/install/share/nqp/lib --libpath=/home/dilbert/repos/rakudo/install/share/nqp/lib --libpath=/home/dilbert/repos/rakudo/install/share/nqp/lib /home/dilbert/repos/rakudo/perl6.moarvm --nqp-lib=blib t/spec/S02-types/num.rakudo.moar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6374700 (LWP 27527)]
1..98
ok 1 - EVAL 1.Num.perl is Num
ok 2 - EVAL 1.Num.perl is 1
ok 3 - EVAL 0.Num.perl is Num
...
[many passing tests skipped]
...
ok 97 - atanh(num)
ok 98 - Literal Nums close to the upper limit are not Inf
# FUDGED!

Thread 2 "moar" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6374700 (LWP 27527)]
0x00007ffff76da6f5 in MVM_multi_cache_find_spesh (tc=0x6760c0, cache_obj=0x42574c0, arg_info=0x7ffff6372330, type_tuple=0x7ffff0e91fc0) at src/6model/reprs/MVMMultiCache.c:500
500	                known_type_st = type_tuple[tt_offset].type->st;
(gdb) bt
#0  0x00007ffff76da6f5 in MVM_multi_cache_find_spesh (tc=0x6760c0, cache_obj=0x42574c0, arg_info=0x7ffff6372330, type_tuple=0x7ffff0e91fc0) at src/6model/reprs/MVMMultiCache.c:500
#1  0x00007ffff771fc1b in optimize_call (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fb150, ins=0x7ffff0d04468, p=0x7ffff0d34ae0, callee_idx=1, arg_info=0x7ffff6372330) at src/spesh/optimize.c:1513
#2  0x00007ffff772169c in optimize_bb_switch (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fb150, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2038
#3  0x00007ffff7721bb3 in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fb150, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2225
#4  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09faf10, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#5  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fac70, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#6  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fa7f0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#7  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fa370, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#8  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff09fa0d0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#9  0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d05aa0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#10 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d05800, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#11 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d05500, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#12 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d05260, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#13 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d04fc0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#14 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d04d20, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#15 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d04a80, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#16 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d047e0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#17 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d04660, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#18 0x00007ffff7721bed in optimize_bb (tc=0x6760c0, g=0x7ffff0d088a0, bb=0x7ffff0d045a0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2229
#19 0x00007ffff77227a1 in MVM_spesh_optimize (tc=0x6760c0, g=0x7ffff0d088a0, p=0x7ffff0d34ae0) at src/spesh/optimize.c:2475
#20 0x00007ffff7714019 in MVM_spesh_candidate_add (tc=0x6760c0, p=0x7ffff0d34ae0) at src/spesh/candidate.c:62
#21 0x00007ffff77299aa in worker (tc=0x6760c0, callsite=0x7ffff7dd5f20 <null_args_callsite>, args=0x0) at src/spesh/worker.c:13
#22 0x00007ffff76bfe4f in invoke_handler (tc=0x6760c0, invokee=0x668e80, callsite=0x7ffff7dd5f20 <null_args_callsite>, args=0x0) at src/6model/reprs/MVMCFunction.c:9
#23 0x00007ffff7676a07 in thread_initial_invoke (tc=0x6760c0, data=0x6777e0) at src/core/threads.c:59
#24 0x00007ffff7638ef8 in MVM_interp_run (tc=0x6760c0, initial_invoke=0x7ffff767697c <thread_initial_invoke>, invoke_data=0x6777e0) at src/core/interp.c:93
#25 0x00007ffff7676ab9 in start_thread (data=0x6777e0) at src/core/threads.c:85
#26 0x00007ffff6b896ba in start_thread (arg=0x7ffff6374700) at pthread_create.c:333
#27 0x00007ffff71af41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) info threads
  Id   Target Id         Frame 
  1    Thread 0x7ffff7fd9700 (LWP 27523) "moar" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 2    Thread 0x7ffff6374700 (LWP 27527) "moar" 0x00007ffff76da6f5 in MVM_multi_cache_find_spesh (tc=0x6760c0, cache_obj=0x42574c0, arg_info=0x7ffff6372330, type_tuple=0x7ffff0e91fc0)
    at src/6model/reprs/MVMMultiCache.c:500
@AlexDaniel
Copy link
Contributor

AlexDaniel commented Jan 30, 2018

For what it's worth, it's possible that it is a regression. rakudo/rakudo@8bed4a67b

<AlexDaniel> c: 8bed4a67b^,8bed4a67b run(:err, :out, :env(%(MVM_SPESH_NODELAY=>1, MVM_SPESH_BLOCKING=>1)), (run :out, ‘which’, ‘perl6-gdb-m’).out.slurp-rest.chomp, ‘sandbox/roast/S02-types/num.t’).out.slurp-rest.contains(‘SIGSEGV’).say
<committable6> AlexDaniel, ¦8bed4a67b^: «False␤» ¦8bed4a6: «True␤»

@dogbert17
Copy link
Contributor Author

There's a slight possibility that the offending MoarVM commit is '388a769 Enable type tuple use in multi-dispatch'.

@dogbert17
Copy link
Contributor Author

Fixed by nine++ with commit 0e73714

@dogbert17
Copy link
Contributor Author

It was a test which uncovered the problem so we don't have to write new ones :)

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

No branches or pull requests

2 participants