|
01:33
MasterDuke joined
11:06
ab5tract left
15:00
ab5tract joined
16:50
MasterDuke left
17:10
ab5tract left
|
|||
| lizmat | m: for 1, 2, 3, 4, 5 -> $n { (say $n for ^5000) xx 2 } | 17:22 | |
| camelia | (signal SEGV)1 | ||
| lizmat | does not happen with MVM_SPESH_DISABLE=1 , so likely a spesh bug | 17:23 | |
| found in github.com/rakudo/rakudo/issues/4192 | |||
| feels this is LHF for someone on #moarvm: github.com/rakudo/rakudo/issues/4225 | 18:01 | ||
| Geth | MoarVM: dogbert17++ created pull request #1844: Update libuv to version 1.49.1 |
18:09 | |
|
18:11
dogbert17 joined
|
|||
| dogbert17 | Here's the changelog for libuv v1.49.1: github.com/libuv/libuv/blob/v1.x/ChangeLog | 18:11 | |
| timo | well, spesh disable is a big hammer, we'd want to try turning osr and inlining off separately and see if any of those also make the crash go away | 18:54 | |
| dogbert17 | Thread 1 "moar" received signal SIGSEGV, Segmentation fault. | 19:36 | |
| 0x00007ffff613beb9 in MVM_interp_run (tc=0x7fffb2020000, initial_invoke=0x7ffff66243e9 <toplevel_initial_invoke>, invoke_data=0x7fffb208c700, outer_runloop=0x0) at src/core/interp.c:6400 | |||
| 6400 found = GET_LEX(cur_op, 2, f); | |||
| (gdb) bt | |||
| #0 0x00007ffff613beb9 in MVM_interp_run (tc=0x7fffb2020000, initial_invoke=0x7ffff66243e9 <toplevel_initial_invoke>, invoke_data=0x7fffb208c700, outer_runloop=0x0) at src/core/interp.c:6400 | |||
| #1 0x00007ffff6624716 in MVM_vm_run_file (instance=0x7fffb2010000, filename=0x7fffffffe0c7 "/home/dilbert/repos/rakudo/perl6.moarvm") at src/moar.c:505 | |||
| #2 0x00005555555578a9 in main (argc=8, argv=0x7fffffffdc08) at src/main.c:307 | |||
| both MVM_SPESH_OSR_DISABLE and MVM_SPESH_INLINE_DISABLE makes the error disappear | |||
| timo | do you want to try the spesh bisect tool from the moar repo on this? | 20:03 | |
| dogbert17 | all I get is MVM_SPESH_LIMIT=76 | 20:30 | |
| timo | does it say it's not having success? i think it's supposed to also spit out a spesh log | 20:33 | |
| where the last entry in the spesh log is what is required for things to go wrong | |||
| dogbert17 | I suspect I need to run the jit-bisect program instead | 20:38 | |
| gist.github.com/dogbert17/4a552082...f0c20826ea | 20:45 | ||
| patrickb | I want to pass an int from rakudo to moar land. On ther moar side MVM_repr_get_int is the tool for the job. But what do I need to put in on the rakudo side? If I use an int64 I get "This representation (NativeRef) cannot unbox to a native int (for type IntAttrRef)". | 20:46 | |
| timo | you want to decont on the rakudo side, maybe nqp::decont_i, maybe nqp::decont, maybe just $blabla<> | 21:07 | |
| dogbert17: i think the jit bisect only does exprjit, but i'm not certain | 21:08 | ||
| patrickb | Thanks! Got it working. | 21:11 | |
| dogbert17 | timo: as far as I can tell there's nothing in spesh-bisect.pl that emits a log !? | 21:57 | |
| timo | could be that you have to grab it manually | 22:07 | |
| i've used it so rarely ... and it's also kind of "only the needed functionality" :D | 22:08 | ||
| dogbert17: at the moment of the segfault, you could also give MVM_dump_bytecode(tc)? and don't count on the "-->" line being correct, there's something wrong with it i think | 22:36 | ||
| it's fun, of course, that the frame that spesh bisect points at isn't where it crashes | 22:37 | ||
| so we may actually want to see what the spesh log after that frame looks like when it's not cut short? to see if it gets inlined somewhere (do we ever inline a dispatcher?) | 22:38 | ||
|
23:24
ab5tract joined
|
|||