| dogbert17 | hmm | 00:00 | |
| could it be that the codepath in question isn't hit that often? | 00:01 | ||
| timotimo | not sure, we can put a debug printf in and see | 00:05 | |
| of course that'd also hit it in the to-be-tested programs if we don't have something clever | |||
| dogbert17 | a quick gdb check show that the code path is hit often | 00:10 | |
| timotimo | ah, gdb is a better idea | 00:11 | |
| you can even put a print in with "commands" and make it immediately resume with "c" before the "end" | 00:12 | ||
| and there's even incantations to prevent it from giving you a pager you have to push return a million times | |||
| we could output messages for each action of adding bytes and discarding bytes and maybe even allocating and freeing a decode stream | 00:23 | ||
| with pointers and such | 00:24 | ||
| they have some pointers that don't move. the object pointer itself is gc-managed probably | |||
| but we could then analyze the log to see if the decodestream that asplodes gets used for long | |||
| maybe output a moar-level backtrace on each action and make it managable by putting it behind a simple UI that allows us to toggle visibility | |||
| AFK, though | |||
| hm. | 00:49 | ||
| i seem to have a hanging test right now | 00:50 | ||
| in one of my runs | |||
| the bar at the bottom is gone, it doesn't consume any cpu | 00:51 | ||
|
01:15
dogbert17 joined
01:29
agentzh joined
03:24
dalek joined,
synopsebot6 joined
05:08
IRCFrEAK joined,
IRCFrEAK left
05:41
agentzh joined
|
|||
| nine | Is there an easy way to print an MVMString to stderr? | 11:02 | |
| Ah, fprintf(stderr, "handle: %s\n", MVM_string_utf8_encode(tc, handle, &size, 0)); seems to do the trick | 11:06 | ||
|
11:29
agentzh joined
|
|||
| jnthn | nine: There's also a MVM_string_utf8_encode_C_string which gives you NULL-terminated | 11:33 | |
| And doesn't ake a size arg | |||
| dogbert17 | jnthn: any opinions on gist.github.com/dogbert17/eaba7dfc...b1748fbe23 ? | 11:46 | |
| nine | Ok, I can now confirm that when the source code is equal, the SC handle is equal and therefore we use the same scb for both modules. | 11:48 | |
| jnthn | nine: Yeah, the SC handle is made by sha1 of the source in Rakudo | 11:53 | |
| Happens when Perl6::World is constructed, iirc | |||
| nine | jnthn: ok, thanks. That just saved me the time for finding out exactly this :) | 11:54 | |
| Of course the open question is, what to actually do about it. | |||
| jnthn | Has it become a problem? | 11:55 | |
| nine | Yes: gist.github.com/ugexe/b8ac60d26a17...62e9716d96 | ||
| jnthn | Well, duh, or you'd not be looking at it | ||
| But why? :) | |||
| nine | Use case is someone forking a dist under a different auth and a program using both the fork and the original. | ||
| For a large dist the chance is high that some modules will be identical in both dists. | 11:56 | ||
| jnthn | At what point does that happen, but we can't just treat it as the same module? | ||
| Or rather, the same compiled output | 11:57 | ||
| Oh, 'cus module precomp storage is not just keyed on source code. | |||
| Hmm | |||
| I guess one possible solution, if we're precompiling a module, is to factor the dist into the sha-1 hash | 11:58 | ||
| Since dist identifies should be unique | 11:59 | ||
| nine | Ah, yes, I've found the code in Perl6::Grammar | 12:00 | |
| I'll have a look at getting the dist-id into there | |||
| jnthn | NQP factors a timestamp in instead iirc, for the sake of bootstrapping | 12:01 | |
| (Where the layers of bootstrap have the same source) | |||
| But that's a bit fragile for general use | 12:02 | ||
| So yeah, dist-id is probably wiser | |||
| nine | Ah, that's where handles like F2C4AFFFA43D84AE3246F1C7874339333BEBBCAA-1487419665.25749 are coming from | ||
| jnthn | You noted on #perl6-dev it's MoarVM to blame, but seems it's more Rakudo not making unique enough IDs...is there something MoarVM coulda done different to catch this problem sooner, though? | ||
| jnthn ain't sure if we get upset if you try to create the same handle twice... | 12:03 | ||
| Well, create SCs with the same handle... | |||
| dogbert17: That one is...intersting, and a bit different. Hmm :) | 12:08 | ||
| nine | Well I did not intend to assign blame :) For that my understanding is much too limited. I do wonder though if there's a valid case where we'd access an already loaded scb when deserializing just loaded bytecode. | 12:09 | |
| jnthn | nine: Yes, I wasn't worrying so much about blame as if we could tweak something in MoarVM so that your bug hunt mighta been shorter. :) | 12:10 | |
| dogbert17 | timotimo and I had a feeling that we might be zeroing in on the right spot ... | ||
| jnthn | nine: ohh...hmm | 12:12 | |
| nine: The MVM_sc_create code is a bit interesting :) | |||
| github.com/MoarVM/MoarVM/blob/mast...el/sc.c#L3 | |||
| I wonder what the explicit "lost the race to create it" thing is about | 12:13 | ||
| (No, I can't remember. :)) | |||
| nine | Well it's diakopter++'s code ;) | 12:14 | |
| jnthn | Oh | ||
| So *that's* why I don't remember writing it :D | |||
| nine | "make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry" | 12:15 | |
| jnthn | That sounds like something that went in very early :) | 12:16 | |
| nine | jnthn: actually including $?FILES in the computed hash seems to fix it. And it may even a valid fix since the hash for the installed source file already contains the $dist-id | 12:18 | |
| jnthn | Aha | 12:20 | |
| And I guess -Ilib is immune to these issues | |||
| lunch; bbiab | 12:27 | ||
|
13:22
pyrimidine joined
13:35
zakharyas joined
13:41
geekosaur joined
15:32
agentzh joined
17:38
pyrimidine joined
|
|||
| dogbert17 | jnthn: does that mean that you have a theory as to what's going wrong? | 17:44 | |
|
18:14
Util joined
18:15
agentzh joined
20:33
agentzh joined
22:11
geekosaur joined
23:16
geekosaur joined
|
|||