|
03:14
tomboy64 joined
03:23
tomboy64 joined
05:49
Util joined
06:10
domidumont joined
06:15
domidumont joined
06:52
tomboy64 joined
07:05
MadcapJake joined
07:15
JimmyZ_ joined
07:22
zakharyas joined
08:36
domidumont joined
|
|||
| jnthn | tomboy64: Don't know anything about that, sorry. :( | 08:53 | |
| tomboy64 | jnthn: i think i figured it out. it was lib64 being set without / what made it a security issue. | 08:54 | |
| jnthn: i changed that in my patch. | |||
| jnthn | ah, ok :) | 08:57 | |
| tomboy64: Left some comments on your MoarVM PR. Looks good overall. | 09:04 | ||
|
09:35
zakharyas joined
09:47
leont_ joined
10:01
Kooda left
|
|||
| dalek | arVM/reframe: 8b642e4 | jnthn++ | src/6model/reprs/MVMThread.c: Mark tc->thread_obj of unstarted threads. Otherwise, if a GC happens between thread creation and thread start, we'll end up with a TC that has an outdated ->thread_obj pointer. |
10:20 | |
| arVM/reframe: 2a022fb | jnthn++ | src/6model/reprs/MVMThread.c: Use MVM_load with an AO_t, to be on the safe side. |
10:21 | ||
| jnthn | That was by far the most common thing we blew up over in S17 tests | 10:27 | |
| Fixing it makes various tests happy, and moves various ones on to their next problem | 10:28 | ||
| nwc10 | is that a general bug, or one specific to your changes? | 10:30 | |
| jnthn | nwc10: That one was a general bug | ||
| nwc10 | aha. *interesting*. That might be why sometimes tests hang for me under ASAN | 10:31 | |
| time & retesting will tell | |||
| I'd not been bothering you about this | |||
| (and it was way beyond my ability to diagnose quickly) | |||
| jnthn | gist.github.com/jnthn/2996cce212da...60e71fe5a5 is latest status | 10:36 | |
| dalek | arVM/reframe: 0861a76 | jnthn++ | src/core/exceptions.c: Missing rooting of frames in backtrace formation. |
10:59 | |
| jnthn | That one actually was due to my changes :) | ||
|
11:01
leont_ joined
11:05
brrt joined
11:16
TimToady joined
|
|||
| jnthn | Gosh, S32-exceptions/misc.t takes an eternity under GC torture | 11:33 | |
| But provided it doesn't explode, that'll be all the ones with a bad object inside an MVMHash fixed | |||
| moritz | it's a big file | ||
| I guess parsing alone is an ordeal :-) | 11:34 | ||
| jnthn | aye | ||
| It's up to test 370 by now :) | |||
| nwc10 | something you just did fixed the nativecall tests | 11:35 | |
| timotimo | GC torture really is extra-bad because we only promote things to the gen2 when they've survived a generation | ||
| jnthn | :) | ||
| timotimo | so i expect we'll end up doing two GCs back-to-back with almost nothing freed in between quite often | ||
| jnthn | Aye, though that's in part why it catches quite a lot of bugs | ||
| timotimo | btw, do we have any code in place to make sure that when the nursery didn't shrink after a gc run we don't asplode directly after the GC run? | ||
| jnthn | Yes :) | 11:36 | |
| timotimo | good | ||
| jnthn | Pretty sure that's been in there since day 1 | ||
| timotimo | not like we'll ever hit that code path in regular user code :) | ||
| um, actually ... the string split case could hit that | |||
| jnthn | Or, the first day we allocated objects :) | ||
| timotimo | when we split a gigantic string into a crapton of chunks | ||
| jnthn | For the first while there was no GC, so it was like "4MB should be enough for everyone" :) | 11:37 | |
| timotimo | :D | ||
| we wouldn't have gotten far in rakudo code with that attitude | |||
| jnthn | It did run quite a few of the NQP tests though :) | 11:38 | |
| Noting that we "cross-compiled" them | 11:39 | ||
| timotimo | not so important any more :) | 11:40 | |
| jnthn | lunch & | 11:42 | |
|
11:42
TimToady joined
11:48
leont_ joined
|
|||
| dalek | arVM: 2e059d9 | timotimo++ | src/6model/reprs/P6opaque.c: "this type" will now actually mention the type |
11:49 | |
| arVM: 350a1ba | timotimo++ | src/6model/reprs/P6opaque.c: "missing serialize" and "rebless" also mention type now Uninstantiable will now error with debug name |
|||
| timotimo | ^- i decided the code's good enough to get merged, as we just had the release | ||
|
11:49
dalek joined
|
|||
| timotimo | This improves a bunch of error messages, especially when they used to | 11:50 | |
| say "this type", but not *what* type. On top of that, some additional | |||
| errors gained a bit more detail, like in P6opaque's compose. And also | |||
| errors like "this type doesn't support associative operations" (and | |||
| same for positional) now tell you what operation was attempted. | |||
| github.com/MoarVM/MoarVM/commit/1c...7d97fc5b61 | |||
| jnthn | timotimo: Sound like nice error-reporting improvements | 12:05 | |
|
12:07
domidumont joined
|
|||
| timotimo | i hope people find it useful | 12:10 | |
| jnthn | I suspect so :) | 12:17 | |
| arnsholt | That definitely sounds useful! timotimo++ | 12:18 | |
| timotimo | the errors in the compose thing are probably useless unless you write your own object system | ||
| but i figured i might as well. | |||
| jnthn | S32-exceptions/misc.t ran to completion under torture | ||
| moritz | \o/ | 12:19 | |
| arnsholt | timotimo: Just because it's not likely that "ordinary" users will be doing it doesn't mean that we have to make it as painful as possible =) | ||
| I'm generally in favour of having as specific errors as possible | |||
| jnthn | So, which ones next... | ||
|
12:20
domidumont joined
|
|||
| timotimo | :) | 12:24 | |
| oh, "which ones" wasn't refering to error messages :D | |||
| jnthn | no, which things from my list of GC torture failies | 12:25 | |
| jnthn hunted down another one | 12:56 | ||
| Bah, so S07-hyperrace/race.rakudo.moar is now a reliable deadlock rather than a reliable crash :P | 12:59 | ||
| timotimo | yeah, race was rather fragile to begin with :| | 13:02 | |
| jnthn | hyper.rakudo.moar too | ||
| It either runs to completion or deadlocks | 13:05 | ||
| timotimo | aye :\ | ||
| jnthn | Whereas before it fairly reliably SEGV'd due to a GC issue | ||
| timotimo | when reading a perl6 source file we could totally catch a "invalid character in utf8", re-encode with utf8-c8 and give a bit of context around the place to help people figure out what went wrong | 13:07 | |
| someone on reddit reported they put an é (or è?) in a source file and that reliably crapped out, but only later found out that for some unknown reason the editor they used decided to use some non-utf8 encoding even though they always saved as utf8 otherwise | 13:08 | ||
| so when the user expects they've saved something as utf8 and rakudo complains, they'll be convinced rakudo is bugged | 13:09 | ||
| jnthn | S17-procasync/basic.rakudo.moar now seems to reliably fail to crash under torture, so at least I get that one off my list :) | ||
| timotimo | whereas when we show the user the wrong bytes in question, they have a much better idea of what went wrong | ||
| thoughts? | |||
| oh yay :) | |||
| moritz | timotimo: would be awesome | ||
| timotimo | i'll think about that more today; right now i'm off towadrs the sauna :3 | 13:10 | |
| arnsholt | Yeah, that definitely sounds reasonable (and a good idea!) | ||
| timotimo | in addition to that, it'd be swell if we could do a bit more "encoding guessing" | ||
| like "did you expect one of those characters to appear here?" | |||
| "[PILE OF POO] - your file is probably cp1234 | 13:11 | ||
| [UNICORN] - your file seems to be iso-1234-99999" | |||
| "almost every other byte of this file seems to be a null-byte; did you pass a utf-16 or ucs-16 file by accident?" | |||
| don't forget that 2-byte encodings are (allegedly?) really common in at least one of the CJK areas | 13:12 | ||
|
13:14
tomboy64 joined
|
|||
| dalek | arVM/reframe: 7d51049 | jnthn++ | src/core/frame.c: The instrumentation level barrier may allocate. Therefore, root collectables around it. |
13:33 | |
| arnsholt | timotimo: I guess there might be useful code to be snarfed in Python's ftfy module? | 13:34 | |
| jnthn | That one changed the status of 8 things in the list (3 seemingly fixed for good) | 13:38 | |
|
13:46
tomboy64 joined
|
|||
| timotimo | arnsholt: The goal of ftfy is to take in bad Unicode and output good Unicode, for use in your Unicode-aware code. This is different from taking in non-Unicode and outputting Unicode, which is not a goal of ftfy. It also isn't designed to protect you from having to write Unicode-aware code. ftfy helps those who help themselves. | 13:46 | |
| dalek | arVM/reframe: 2698ba7 | jnthn++ | src/core/threads.c: Correct cleanup of temp roots at thread exit. Fixes a crash that could occur when doing GC of an exited thread. |
13:47 | |
| timotimo | the problem that user had on reddit was when we didn't get any unicode out of the encoded blob we read | ||
| jnthn | Current state of play: gist.github.com/jnthn/2996cce212da...60e71fe5a5 | 13:48 | |
| arnsholt | timotimo: Oh, that's right of course. I got it confused a bit | ||
| timotimo | but it was a good suggestion anyway :) | 13:49 | |
| jnthn: nice! | |||
| dalek | arVM/reframe: c0ffff2 | jnthn++ | src/core/frame.c: Mark frame in unwind data, now it's GC-able. |
14:02 | |
| jnthn | That one related to the frames change. | ||
| timotimo | right | 14:03 | |
| jnthn | So far, 2 issues I was hoping to tease out with this torture testing fixed, and 3 others that showed up along the way :) | ||
|
14:10
zakharyas joined
|
|||
| dalek | arVM/reframe: 3fce8d7 | jnthn++ | src/gc/debug.h: This debugging macro is better with panic. Since otherwise, the exception can be caught. Been using it the panic way all day, and it's been rather easier. |
14:23 | |
| arVM/reframe: 32643d1 | jnthn++ | src/core/exceptions.c: Missing root of exception message in `die`. |
|||
| timotimo | oh, that's rather a bad miss :) | 14:25 | |
| jnthn | Yeah, and another one that's not thanks to the frames thing | ||
| But, a fix is a fix. | 14:26 | ||
| timotimo | yup | 14:27 | |
| jnthn | Betting this CUnion one will be nothing to do with frames also... | 14:28 | |
| timotimo | sounds likely | 14:32 | |
| nine_ | jnthn++ # hard to imagine that rakudo even ran with so many bugs | 14:39 | |
| timotimo | haha | 14:40 | |
| jnthn | nine_: It's a matter of probability, really | ||
| These *could* all come up in user's programs and absolutely want fixing, but each rely on GC happening in a very specific place. | |||
| And when you've 4MB of allocation between each collection, along with the fact that many of these places aren't highly common code-paths, it's not so surprising | 14:41 | ||
| timotimo | with many user programs finishing before ~20 GC runs in total, it's hard to hit something so perfectly | ||
| jnthn | Right. Of course, it sucks to be the unlucky user who ends up with the SEGV or weird internal error. | 14:42 | |
| timotimo | yes. very. | ||
| jnthn | And it sucks to be us faced with such a bug report, because details like the number of env vars they had could be enough to hide it | 14:43 | |
| timotimo | we really ought to be able to build some kind of instrumentation (at the C level) that traverses callframes whenever an allocation call is made and checks to see if variables have been rooted or not | ||
| nine_ | Like the NaticeCall temp root bug a year ago that took months just to reproduce with an attached gdb | 14:44 | |
| jnthn | The CUnion one could also explain a little flappiness we saw in the nativecall union tests a while ago | 14:45 | |
| dalek | arVM/reframe: 6733e92 | jnthn++ | src/6model/reprs/CUnion.c: Fix CUnion layout computation GC issues. An unfortunately-timed GC in the middle of that could end up leaving dangling pointers. Just allocate this layout-related bits in gen2, as they'll probably live for a while anyway. |
14:47 | |
| jnthn | gist.github.com/jnthn/2996cce212da...60e71fe5a5 updated, for those following along :) | 14:51 | |
| moritz | jnthn: did you ever do a similar torture run in master? | 14:53 | |
| jnthn | moritz: Quite a while ago | 14:55 | |
| moritz: It kinda wants automating. | |||
|
14:55
ChanServ joined
|
|||
| jnthn | moritz: But it ties up my quad-core box for the at least half a day | 14:55 | |
| So not like we could run it on travis or something | 14:56 | ||
| moritz | jnthn: understandable :-) | 15:00 | |
| jnthn | Gee, S15-nfg/many-threads.t is pretty upset... | 15:02 | |
| tomboy64 | grml | ||
| masak .oO( no freading good ) | |||
| tomboy64 | somehow i managed to break rakudo compilation | ||
| and i'm really struggling to understand how | 15:03 | ||
| bpaste.net/show/639b63cc1986 | 15:04 | ||
| jnthn | I don't think it's anything to do with NFG | ||
| Given it's a bogus ->outer pointer that it's tripping over | |||
| Darn, this one is proving a good bit trickier to find too... | 15:25 | ||
| timotimo | tomboy64: you shouldn't expect rakudo-jvm to build and run properly today | 16:00 | |
| jnthn | I thought it built fine but had a bunch of test fails? | ||
| tomboy64 | timotimo: the very same package built and ran fine a couple of days ago | 16:01 | |
| timotimo | we didn't have a 2016.04 a few days ago; was it perhaps the 2016.01 release? | ||
| i'll be AFK for a bit | 16:02 | ||
| tomboy64 | rakudo.org/downloads/2016.04/rakudo....04.tar.gz | 16:03 | |
| but true, i might have tried the 2016.03 one | |||
|
16:25
domidumont joined,
zakharyas joined
|
|||
| jnthn | Urgh, think I'll leave this one for today and come back to it when less tired from all the other fixes. :) | 16:27 | |
| mst | NOT ALLOWED | 16:40 | |
| mst injects jnthn with amphetamines | |||
| nine_ | .oO(ETOOMANYFIXES?) |
17:33 | |
|
17:59
colomon joined
18:16
tomboy64 joined
18:28
Ven joined
19:46
colomon joined
|
|||
| dalek | arVM/reframe: e52d1bb | jnthn++ | src/gc/roots.c: Mark tc->thread_entry_frame. Now that frames are collectable, and so can move, this pointer must be marked so it is kept up to date. Otherwise, it points to junk that may one day align with the address of an actually executing frame, causing a worker thread to silently exit and typically resulting in a deadlock because another thread is blocked on its work. |
20:14 | |
| jnthn | That took some darn finding. | ||
| [Coke] | jnthn++ | 20:15 | |
| timotimo | wow, god damn it | 20:16 | |
| that sounds *nasty* | |||
| that'd be hyperrace right there? | |||
| jnthn | Well, a bunch of tests went from "exploding" to "usually deadlock" | 20:17 | |
| Those were two of them | |||
| timotimo | well, did it go from deadlock to works fine with that last commit? is what i meant | 20:19 | |
| jnthn | timotimo: yes | ||
| timotimo | awesome! | ||
| jnthn | Well, as fine as it works on master | ||
| timotimo | :) | ||
| yeah | |||
| jnthn | I was a little suspicious something in the changes I'd done was causing new deadlocks to appear | 20:20 | |
| It seemed like an odd new failure mode. | 20:21 | ||
| Especially when I'd expect regular nursery collects to make them less likely rather than more likely. | |||
| timotimo | :D | ||
| jnthn | Along the way, I found that there's probably a bug in handling of the "in a gen2 inter-gen set", and that Promise is vulnerable to a spurious wake-up | 20:22 | |
| timotimo | urgh | ||
| jnthn | (Got a local patch for the first and know how to fix the second) | 20:23 | |
| timotimo | i have to read up on what spurious wakeups are and what causes them and such | ||
| jnthn | Looks like the deadlocking S17-procasync/no-runaway-file-limit.t doesn't any more either. Alas, it does exhibit a different problem. | 20:30 | |
| timotimo | that just means it's still worth something :) | 20:31 | |
| jnthn | aye | ||
| timotimo | twitter.com/loltimo/status/725413721921753089 - did you see my little shiny? :) :) | ||
| jnthn | ooh, nice | 20:32 | |
| timotimo++ | |||
| timotimo | \o/ | ||
| and jnthn++ for utf8-c8 | |||
|
20:38
colomon joined
20:55
colomon joined
|
|||
| dalek | arVM/reframe: d956008 | jnthn++ | src/gc/roots.c: Fix clearing of "in inter-gen set" flag. Previously, we toggled it. However, multiple threads can have the same collectable in their inter-gen set, and may end up considering it. All the flag does is avoid duplicate additions, so it's safe to clear it when it could be set. However, before this fix we might have ended up with it set when it should not have been, which would be bad. |
20:58 | |
| timotimo | oh lord | 20:59 | |
| jnthn | gist.github.com/jnthn/2996cce212da...60e71fe5a5 # final update for today :) | 21:05 | |
| timotimo | great progress! | 21:06 | |
| ilmari | jnthn: wouldn't gen2roots[i]->flags &= ~MVM_CF_IN_GEN2_ROOT_LIST; be sufficient? | ||
| instead of the & and ^= | |||
| jnthn | ilmari: Hm, yeah, that'd be another way to write it, and get rid of a branch. | 21:08 | |
| dalek | arVM/reframe: 42654cc | jnthn++ | src/gc/roots.c: Simplification thanks to ilmari++. |
21:13 | |
| jnthn | OK, really enough for today :) | 21:14 | |
| timotimo | in that case, i wish you a good rest :) | 21:15 | |
| jnthn | Thanks! 'night all | 21:16 | |
|
21:43
leont_ joined
21:44
colomon joined
21:53
colomon joined
22:33
leont_ joined
23:07
geekosaur joined
23:39
leont_ joined
23:56
synopsebot6 joined
|
|||