|
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:40 | |
|
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. |
13:45 | |
| 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 :) | |||
| FROGGS | :o) | ||
| 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 ;) | |||
| FROGGS | hmmm | ||
|
21:34
ggoebel joined
23:55
lizmat joined
|
|||