Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-07

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:50 TimToady joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:12 camelia joined #moarvm
07:04 domidumont joined #moarvm
07:23 FROGGS joined #moarvm
08:26 zakharyas joined #moarvm
08:49 Ven joined #moarvm
10:07 brrt joined #moarvm
10:24 brrt this morning i've learned that my planned solution of inserting loads and stores - splitting live ranges, as it were - is considered perfectly orthodox by the compiler community
10:24 brrt so that's something, at least
12:47 Ven joined #moarvm
12:59 zakharyas joined #moarvm
13:01 brrt joined #moarvm
13:24 zakharyas joined #moarvm
13:30 zakharyas1 joined #moarvm
14:43 [Coke] https://gist.github.com/coke/5cd2da873f147ef1b7a5 - sigabort I'm getting on OS X.
14:47 brrt doesn't look terribly jit-related to me
14:48 brrt not that it's good, just that i'm not going to look there :-)
14:51 [Coke] I have no idea how to get more info on that.
14:51 virtualsue joined #moarvm
14:51 brrt :-(
14:58 timotimo well, you can set the environment variables that kick out the jit, or inlining, or spesh altogether
14:59 timotimo it kind of looks like something hit an abort() somewhere and that killed your program
15:04 timotimo [Coke]: if you reproduce that, maybe you could give us a full backtrace? and also see if multiple threads are involved? and disabling the jit always gives better stack traces ...
15:09 [Coke] it's a supply test.
15:10 [Coke] how to get a full backtrace with lldb?
15:10 [Coke] it's super reproducable, but not very golfable.
15:10 brrt step 1: you install gdb :-P
15:10 brrt hmm
15:10 brrt maybe someone else can golf it
15:10 [Coke] Here's my current script that generates it:
15:11 [Coke] https://gist.github.com/coke/5cd2da873f147ef1b7a5#file-fail-t
15:11 [Coke] removing any of several dozen of those OK lines avoids the abort.
15:12 brrt hmmm
15:12 brrt well that does sound like a spesh-ish issue
15:12 brrt or jittish
15:12 brrt any of the two
15:13 [Coke] ahh, here's a backtrac: https://gist.github.com/coke/5cd2da873f147ef1b7a5#file-lldb-bt
15:13 [Coke] MVM_DISABLE_SPESH?
15:13 [Coke] [6~
15:14 [Coke] MVM_SPESH_DISABLE=1 ... # still aborts
15:15 [Coke] ditto JIT
15:16 brrt hmmmpf
15:16 [Coke] timotimo: that bt help?
15:16 timotimo in gdb you get all threads' bt with "thread apply all bt"
15:17 timotimo no clue if lldb does it similar to tthat
15:17 brrt [Coke], that's already pretty clear :-)
15:17 [Coke] one sec.
15:17 timotimo so we're destroyign a mutex and that doesn't go over well?
15:17 brrt probably destroying it twice
15:17 timotimo probably, yeah
15:17 timotimo maybe work passing between threads is bust?
15:18 timotimo Show the stack backtraces for all threads.
15:18 timotimo (gdb) thread apply all bt (lldb) thread backtrace all
15:18 timotimo (lldb) bt all
15:18 [Coke] timotimo: look again
15:18 timotimo ah, the other threads are waiting for thread #1 to finish, i expect
15:18 [Coke] this is a day old rakudo. pulling to make sure it still dies...
15:19 timotimo or they are waiting for more work to come their way perhaps
15:22 [Coke] yup, still dies after updating to HEAD
15:23 timotimo i don't think moar has recently seen changes in that area either
15:24 timotimo i know we can work around this problem by checking if a mutex is still alive before we try to destroy it, but there's gotta be some correctness problem with that
15:27 Ven joined #moarvm
15:35 [Coke] If you want, I can test out a patch.
15:38 timotimo i'll be AFK again for a bit in a few minutes
15:38 timotimo so i can neither reproduce nor patch :(
15:42 * [Coke] will hope jnthn shows up in a kibo-like fashion when I mention his name.'
15:43 jnthn If I had to guess, we're hosing up closures or phasers somewhere and so mis-releasing or non-releasing the mutex.
15:43 [Coke] it WORKED
15:44 [Coke] hi, jnthn++. :)
15:44 jnthn I think the best stragety will be to log a backtrace of every mutex we allocate with its object ID, and then if we find it's still held in gc_free dumping out said object ID
15:44 jnthn Then can search the log
15:44 jnthn hi [Coke] :)
15:52 [Coke] oh, this might be a dupe of 126774
15:52 brrt jnthn++ for sanity :-)
16:01 jnthn That's a stretch... :-)
16:03 flussence is there any plan to send patches for 3rdparty stuff upstream? there's a handful of nqp tests that fail when --has-libtommath is used, probably roast tests too.
16:03 moritz flussence: we've sent patches upstream, and some have been merged
16:03 moritz flussence: what we're missing is a new release from libtommath
16:04 flussence oh, I guess they just haven't released anything since 2010...
16:04 moritz flussence: and the distributors only uses releases
16:19 brrt if that is true, should we not kill --has-libtommath
16:20 brrt alternatives are {forking,releasing-it-ourselves}
16:20 flussence a warning in 3rdparty/readme that 0.42.0 is too old and you'd need to build from git would be enough
17:01 jnthn The problem is that various distros have "dynamic linking" as a core value.
17:02 jnthn If it were left to me, we'd just bundle all we use.
17:02 jnthn But that's not the way the world works, sadly.
17:04 jnthn If we had the "install the modules you want per project, perhaps from a local mirror" culture in the Perl world, we'd be having a lot less problems with precomp stuff right now.
17:43 flussence the good news is... I've got nothing better to do right now than experiment with configure switches so it's actually getting tested. And there's only a tiny amount of breakage from that one, using the distro for the other libs works fine :)
17:45 [Coke] jnthn: I can try to add that logging if it will help, but would need a kick in the right direction.
17:45 [Coke] (for the SIGABRT)
17:51 virtualsue joined #moarvm
17:59 vendethiel joined #moarvm
18:16 jnthn [Coke]: It'd be a matter of doing a printf that calls the same thing that objectid does, and calling MVM_dump_backtrace(tc), in the initialize function in ReentrantMutex.c.
18:16 jnthn dinner &
18:17 timotimo i had dinner, too
18:17 timotimo that plan sounds good
19:01 virtualsue joined #moarvm
19:02 Peter_R joined #moarvm
19:03 llfourn joined #moarvm
21:04 leont joined #moarvm
21:07 lizmat m: say "नि".codes
21:07 camelia rakudo-moar 328e95: OUTPUT«2␤»
21:08 lizmat could someone mention that current rakudo *does* say 2 instead of 3 ?
21:08 lizmat at https://news.ycombinator.com/item?id=10690499
21:08 lizmat oops, ww
22:16 diakopter oo I like that .NFC>>.uniname.perl;
22:16 diakopter i like >>. in general
22:18 timotimo me, too
22:18 timotimo so convenient!
22:31 lizmat diakopter: but you cannot know the order anymore like that?
22:32 lizmat ah, no, it will preserve order, but possibly not in execution
22:32 lizmat .oO( doing too much async stuff atm )
22:33 diakopter lol
23:31 virtualsue joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary