| IRC logs at
Set by AlexDaniel on 12 June 2018.
japhb_ nwc10++ # Unrotting the bits 00:19
timotimo ohai japhb 01:10
how's things?
06:20 frost-lab joined
nwc10 good *, #moarvm 07:20
07:22 evalable6 joined 07:23 linkable6 joined 08:16 sena_kun joined 10:14 leont joined
jnthn good * 10:16
nine good good! 11:01
nqp::exit really doesn't play well together with --full-cleanup. E.g. we may still have locked locks like quite ironically $the-end-locker. 11:02
Well our profiler is at least very consistent: it doesn't free any of its memory, ever. 11:11
11:12 squashable6 joined
jnthn Yup, another of those "we'll be exiting anyway, why do what the OS will do" :) 11:17
We might still have locked locks in a normal exit (e.g. all foreground threads finish) too 11:18
nine I worked around this by just unlocking all mutexes in gc_free if we're in global destruction already 11:24
jnthn Hm, can you just do that? I thought wrong thread unlocking a mutex was an abort also... 11:38
MasterDuke jnthn: extracting out the new MVMSpeshCandidatesAndArgGuards struct isn't going as easily as i'd hoped. maybe i should have started from a blank slate instead of adopting what i'd tried first. if you've a couple min to spare, does look like it's on the right track? or am i 11:44
missing something blindingly obvious? i feel like i keep adding new conditionals that i wasn't expecting to need
nine jnthn:'re right. Unlocking a foreign mutex results in either undefined behavior or an error returned 11:49
But, all hope may still not be lost. I can't do anything about someone manually locking a lock and allowing a thread to end with the lock in this state. But all well behaved code should be ok. After all full-cleanup does end all foreground and background threads gracefully 11:51
jnthn nine: I dunno, if I have a background worker that I don't care when gets pulled down, and it may acquire a mutex on occasion, then I don't think it's especially badly behaved 11:55
But it would be in trouble
(In the full-cleanup state) 11:56
11:57 Altai-man joined
nine So far to be OK with full-cleanp your background worker has to react to getting a vmnull from a queue by exiting and unlocking any mutex is holds. I guess that's reasonable to ask for? 11:57
12:00 sena_kun left
jnthn Yes, though of course that means that --full-cleanup changes the semantics in that a task on the threadpool now can block shutdown 12:00
Given this mode is primarily for our own leak finding, though, I don't think that's a big deal 12:01
nine If your worker doesn't implement this, you may end up with a hang on exit or maybe an abort when run with full-cleanup. You'd get a panic now
The other use case is embedding. But there one can probably assume that either the code is more tightly controlled by the embedder anyway or additional rules can apply
12:38 frost-lab left
timotimo could put in a timeout that panics the vm if a thread doesn't react to the shutdown request in time 13:07
also, we could inject exceptions into other threads as long as we can get them to wake up and run into a gc barrier 13:08
nwc10 this would be "wake up, time to die" ? 13:11
timotimo a good day to die in glorious combat!
[Coke] Qapla'! 13:14
13:54 zakharyas joined 14:47 rypervenche joined 15:26 vrurg_ joined 15:29 vrurg left 15:59 sena_kun joined, Altai-man left 16:00 brrt joined
brrt good * 16:01
nwc10 good *, brrt
16:40 patrickb joined 16:46 patrickb left
Geth MoarVM/asan_fixes: 4 commits pushed by (Stefan Seifert)++ 16:50
17:07 leont left 17:17 Kaiepi left 17:43 domidumont joined 18:13 Kaiepi joined 18:16 domidumont left 18:19 ggoebel joined
ggoebel #raku 18:19
brrt ohai ggoebel 18:39
ggoebel o/ 18:40
brrt .tell nine it may be worth having a MVM_VECTOR_PARAM(x) macro that specifies the vector as a parameter, and maybe an equivalent MVM_VECTOR_ARG(x) that does the same for arguments
tellable6 brrt, I'll pass your message to nine
18:49 zakharyas left 19:13 leont joined 19:47 brrt left 19:57 zakharyas joined, Altai-man joined 20:00 sena_kun left 20:06 tobs joined 20:11 tobs left 20:14 tobs joined 20:18 tobs left 20:21 tobs joined 21:00 tobs left 21:06 tobs joined 21:09 ggoebel left 21:11 tobs left 21:15 ggoebel joined 21:16 brrt joined 21:19 tobs joined 21:22 rypervenche left 21:25 rypervenche joined 21:35 zakharyas left
MasterDuke interesting. i now get a bit further in the nqp build, but get a segv in MVM_str_hash_key_is_valid, and the backtrace doesn't have any code i touched 21:52
timotimo: btw, i now get a bunch of new warnings in debugserver code 21:54
after i rebased my branch to master
timotimo i bet it's format strings again 22:01
MasterDuke nope 22:03
timotimo ah, those are harmless but can still be fixed easily 22:04
22:07 Altai-man left 22:30 brrt left