01:50 TimToady joined 02:47 ilbot3 joined 03:12 camelia joined 07:04 domidumont joined 07:23 FROGGS joined 08:26 zakharyas joined 08:49 Ven joined 10:07 brrt joined
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
so that's something, at least
12:47 Ven joined 12:59 zakharyas joined 13:01 brrt joined 13:24 zakharyas joined 13:30 zakharyas1 joined
[Coke] gist.github.com/coke/5cd2da873f147ef1b7a5 - sigabort I'm getting on OS X. 14:43
brrt doesn't look terribly jit-related to me 14:47
not that it's good, just that i'm not going to look there :-) 14:48
[Coke] I have no idea how to get more info on that. 14:51
14:51 virtualsue joined
brrt :-( 14:51
timotimo well, you can set the environment variables that kick out the jit, or inlining, or spesh altogether 14:58
it kind of looks like something hit an abort() somewhere and that killed your program 14:59
[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:04
[Coke] it's a supply test. 15:09
how to get a full backtrace with lldb? 15:10
it's super reproducable, but not very golfable.
brrt step 1: you install gdb :-P
hmm
maybe someone else can golf it
[Coke] Here's my current script that generates it:
gist.github.com/coke/5cd2da873f147...ile-fail-t 15:11
removing any of several dozen of those OK lines avoids the abort.
brrt hmmm 15:12
well that does sound like a spesh-ish issue
or jittish
any of the two
[Coke] ahh, here's a backtrac: gist.github.com/coke/5cd2da873f147...le-lldb-bt 15:13
MVM_DISABLE_SPESH?
[6~
MVM_SPESH_DISABLE=1 ... # still aborts 15:14
ditto JIT 15:15
brrt hmmmpf 15:16
[Coke] timotimo: that bt help?
timotimo in gdb you get all threads' bt with "thread apply all bt"
no clue if lldb does it similar to tthat 15:17
brrt [Coke], that's already pretty clear :-)
[Coke] one sec.
timotimo so we're destroyign a mutex and that doesn't go over well?
brrt probably destroying it twice
timotimo probably, yeah
maybe work passing between threads is bust?
Show the stack backtraces for all threads. 15:18
(gdb) thread apply all bt (lldb) thread backtrace all
(lldb) bt all
[Coke] timotimo: look again
timotimo ah, the other threads are waiting for thread #1 to finish, i expect
[Coke] this is a day old rakudo. pulling to make sure it still dies...
timotimo or they are waiting for more work to come their way perhaps 15:19
[Coke] yup, still dies after updating to HEAD 15:22
timotimo i don't think moar has recently seen changes in that area either 15:23
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:24
15:27 Ven joined
[Coke] If you want, I can test out a patch. 15:35
timotimo i'll be AFK again for a bit in a few minutes 15:38
so i can neither reproduce nor patch :(
[Coke] will hope jnthn shows up in a kibo-like fashion when I mention his name.' 15:42
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
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
Then can search the log
hi [Coke] :)
[Coke] oh, this might be a dupe of 126774 15:52
brrt jnthn++ for sanity :-)
jnthn That's a stretch... :-) 16:01
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
flussence: what we're missing is a new release from libtommath
flussence oh, I guess they just haven't released anything since 2010... 16:04
moritz flussence: and the distributors only uses releases
brrt if that is true, should we not kill --has-libtommath 16:19
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
jnthn The problem is that various distros have "dynamic linking" as a core value. 17:01
If it were left to me, we'd just bundle all we use. 17:02
But that's not the way the world works, sadly.
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:04
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:43
[Coke] jnthn: I can try to add that logging if it will help, but would need a kick in the right direction. 17:45
(for the SIGABRT)
17:51 virtualsue joined 17:59 vendethiel joined
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
dinner &
timotimo i had dinner, too 18:17
that plan sounds good
19:01 virtualsue joined 19:02 Peter_R joined 19:03 llfourn joined 21:04 leont joined
lizmat m: say "नि".codes 21:07
camelia rakudo-moar 328e95: OUTPUT«2␤»
lizmat could someone mention that current rakudo *does* say 2 instead of 3 ? 21:08
at news.ycombinator.com/item?id=10690499
oops, ww
diakopter oo I like that .NFC>>.uniname.perl; 22:16
i like >>. in general
timotimo me, too 22:18
so convenient!
lizmat diakopter: but you cannot know the order anymore like that? 22:31
ah, no, it will preserve order, but possibly not in execution 22:32
.oO( doing too much async stuff atm )
diakopter lol 22:33
23:31 virtualsue joined