00:19 nebuchad` joined, dalek joined 01:22 vendethiel joined 02:48 ilbot3 joined 07:37 domidumont joined 08:19 zakharyas joined
jnthn moarning o/ 09:22
11:52 domidumont joined
[Coke] hio 12:25
dalek arVM: a4c0a84 | jnthn++ | src/jit/emit_x64.dasc:
Fix JIT code generation bug in nqp::exception.

It did a dereference to many, thus ending up reading the wrong thing.
12:52 vendethiel joined 13:32 vendethiel- joined
dalek arVM: e998e2e | jnthn++ | src/6model/reprs/ConcBlockingQueue.c:
Add missing rooting of value pushed to conc queue.

Fixes an occasional crash resulting from an outdated pointer being left in the queue if we got unlucky with when GC runs took place.
arVM: ec45ae2 | jnthn++ | build/Makefile.in:
Add src/gc/debug.h dependency to Makefile.
14:30 lizmat joined 14:54 synopsebot6 joined
timotimo now this is certainly strange ... 15:04
deserialize_sc_deps was callocing something, then gc_collect_free_nursery_uncopied freed it, then MVM_sc_get_object (via MVM_interp_run) stumbled upon a piece of its insides
but that's inside gc_global_destruction, so that's probably okay
jnthn Hm, that suggests global des isn't syncing up all threads properly 15:14
timotimo clearly 15:16
if one's still in MVM_interp_run, and another is in gc_global_thermonuclear_war, that's bad 15:17
but i can't get earlier failures under valgrind to show up 15:18
even though just running it gives me more kinds of failure than i can shake a stick at
15:25 dogbert17_ joined
dogbert17_ timotimo: are you fighting the same problems which shows up in RT #129832 ? 15:27
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129832
timotimo ah 15:28
that bug is just "multiple threads will explode when --full-cleanup is passed"
dogbert17_ aha, so slightly different then 15:29
timotimo no, it's pretty much the same thing
the title is misleading, of course 15:30
dogbert17_ what should it say?
timotimo something something --full-cleanup something threads something unsynchronized something, maybe? 15:31
dogbert17_ :-)
timotimo the thing is
it's not that the test "sometimes generates invalid reads under valgrind"
it's "sometimes does invalid things when run with --full-cleanup"
dogbert17_ ah, I see
timotimo but "under valgrind" implies "--full-cleanup"; the important thing is the full cleanup, not valgrind 15:32
dogbert17_ I see, dunno if I can change the title though 15:33
there's one other test (not in roast) which generates invalid reads but I haven't been able to 'trick' nine into fixing it yet :-) 15:35
timotimo i think i can
Ticket 129832: Subject changed from '[BUG] t/spec/S17-supply/start.t sometimes generates invalid reads under valgrind' to '[BUG] t/spec/S17-supply/start.t can cause invalid reads from unsynchronized --full-cleanup instance teardown' 15:36
does that sound sane? 15:37
dogbert17_ sure
15:40 MasterDuke_ joined
MasterDuke_ timotimo: i noticed you mentioned something about MVM_exception_backtrace_line(). if you compare it and MVM_exception_backtrace(), they have similar but not identical ways of getting the filename 15:41
MVM_exception_backtrace_line: MVMString *filename = cur_frame->static_info->body.cu->body.filename; 15:42
MVM_exception_backtrace: filename_str = fshi >= 0 && fshi < cur_frame->static_info->body.cu->body.num_strings ? MVM_cu_string(tc, cur_frame->static_info->body.cu, fshi) : cur_frame->static_info->body.cu->body.filename;
are those differences legit? 15:43
timotimo it should probably be the second both times? 15:44
it's possible that the file name hasn't yet been decoded
there's some code in moar so that we don't have to go and decode every string in the string heap on startup
MasterDuke_ could that have caused the segfault you got? 15:48
timotimo yeah. but at that point the interpreter was already dying
i closed the terminal that had the output 15:49
MasterDuke_ rule 2 - the double tap
16:03 vendethiel joined 16:39 FROGGS joined
FROGGS o/ 16:44
domidumont \o 16:45
17:37 zakharyas joined
FROGGS slow mips*el is slow :o( 17:41
18:19 brrt joined 18:31 zakharyas joined 18:43 lizmat joined
FROGGS help: github.com/ivmai/libatomic_ops/iss...-257673959 19:56
brrt? any hints? 20:08
it is about this: github.com/ivmai/libatomic_ops/blo...s390.h#L44
20:20 zakharyas joined
FROGGS xkcd.com/371/ 20:25
jnthn Hmmm :) 20:27
Well, I guess we can take wild guesses :P 20:29
FROGGS thing is... I'd probably have to study CS and read a lot about this architecture just to understand the few lines to copy... 20:33
jnthn I think I understand what it's saying in the manual, but the wording is a bit confusing 20:35
FROGGS laughs about xkcd.com/234/
jnthn: what manual?
jnthn The PDF referenced at the top of the .c file you linked :) 20:37
FROGGS looks
jnthn FROGGS: Ummm....will this even compile? gist.github.com/jnthn/9cc24984158f...a7d89bd3ed 20:40
FROGGS test.c:18:3: error: output operand constraint lacks '=' 20:44
: "cc", "memory");
jnthn haha 20:45
so much for that :)
jnthn afk for a bit
but basically what we need to do I *think* is just the cs or csg instruction 20:46
And retval should be what's in the second register that op takes
so far as I understand the docs ;)
21:34 ggoebel joined 23:55 lizmat joined