Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2018-01-03

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 lizmat joined #moarvm
00:22 geekosaur joined #moarvm
01:31 geekosaur joined #moarvm
02:16 FROGGS_ joined #moarvm
02:36 Kaiepi joined #moarvm
02:59 ilbot3 joined #moarvm
02:59 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:16 Kaiepi joined #moarvm
03:21 Kaiepi joined #moarvm
06:23 geospeck joined #moarvm
07:15 FROGGS joined #moarvm
08:13 gfldex joined #moarvm
08:20 andrzejku joined #moarvm
09:04 zakharyas joined #moarvm
09:11 leont_ joined #moarvm
09:17 gfldex left #moarvm
09:24 domidumont joined #moarvm
09:31 domidumont joined #moarvm
09:35 committable6 joined #moarvm
09:56 leont_ joined #moarvm
11:44 domidumont joined #moarvm
12:02 reportable6 joined #moarvm
12:08 MasterDuke joined #moarvm
12:10 dogbert2 jnthn: have you recovered from your nasty flu yet?
12:59 jnthn dogbert2: Yeah, by now it's just lingering little bits of cold symptoms and tiredness
12:59 yoleaux 04:08Z <Zoffix> jnthn: made `Foo:D(Bar)` coercers work, if you wanted to sanity check: https://github.com/rakudo/rakudo/commit/fc99d5e1cd#diff-a81a8247fe9a4f902ab6f14a3314ccc2R1599  FYI: next gonna implement type-checking of result after coersion + trying to do `Target.new: Original` coersion if `Original.Target` fails
13:08 zakharyas joined #moarvm
13:09 statisfiable6 joined #moarvm
13:11 nativecallable6 joined #moarvm
13:28 dogbert2 jnthn: sounds promising. Let me know when you're fresh enough to try to answer a question :)
13:48 dogbert2 .seen timotimo
13:48 yoleaux I saw timotimo 13:45Z in #perl6: <timotimo> right, very tight recursion is a very good way to make moarvm allocate and use memory really, really fast
13:49 timotimo o/
13:49 dogbert2 o/ do you have time for a question regarding a SEGV?
13:49 timotimo i can give it a try
13:50 dogbert2 this line: https://github.com/MoarVM/MoarVM/blob/master/src/gc/collect.c#L315
13:51 dogbert2 'item' points to an MVMCollectible-something but REPR(item) becomes null
13:51 dogbert2 what could cause that to happen, any ideas?
13:52 dogbert2 that's question number one :)
13:52 timotimo ah, that one
13:52 dogbert2 :-)
13:53 timotimo i thought at first that it might just not have been copied over completely yet and that's why it's still null
13:53 timotimo but that access is going to the copy source, not the destination, right?
13:53 dogbert2 I believe so. I don't know what REPR does though
13:54 dogbert2 I get this when enabling COLLECTION messages in orchestrate.h
13:55 dogbert2 which leads me to question no 2
13:56 timotimo the STable (Shared Table) is a structure containing a type object and a REPR; that's how the repr hangs off of an object
13:56 timotimo the REPR has, among other things, a whole bunch of function pointers that handle all kinds of things, like positional or associative accessing, boxing/unboxing, creation, type composition, serialization and deserialization, ...
13:56 dogbert2 could the object, i.e. item be corrupt then since the REPR call returns null
13:57 timotimo maybe have a closer look at the STABLE(foo) first
13:57 dogbert2 that can be arranged :) but first another question :)
13:58 dogbert2 if you check https://github.com/MoarVM/MoarVM/blob/master/src/gc/collect.c#L328 you'll see that the call to GCDEBUG_LOG is 'protected' by 'if (MVM_GC_DEBUG_ENABLED(MVM_GC_DEBUG_COLLECT)' but that is not the case on line 315
13:59 dogbert2 doesn't that mean that line 315 is always executed
14:00 timotimo the GCDEBUG_LOG macro actually also has a condition just like that in it
14:00 dogbert2 indeed, but isn't the REPR thing executed at the very least?
14:01 dogbert2 or is the compiler smarter than that
14:04 dogbert2 ok, now I'm in gdb after the SEGV, i.e. at
14:04 dogbert2 315                 GCDEBUG_LOG(tc, MVM_GC_DEBUG_COLLECT, "Thread %d run %d : copying an object %p (reprid %d) of size %d to tospace %p\n",
14:04 dogbert2 gdb) p item
14:04 dogbert2 $1 = (MVMCollectable *) 0xb74eb4c8
14:05 dogbert2 (gdb) p REPR(item)
14:05 dogbert2 $2 = (const MVMREPROps *) 0x0
14:06 jnthn p *item ?
14:06 jnthn Or more interesting maybe
14:06 jnthn p item->flags
14:06 dogbert2 (gdb) p *item
14:06 dogbert2 $3 = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, sci = 0x0, st = 0x0}, owner = 1, flags = 4, size = 112}
14:07 jnthn /* Is a heap-promoted call frame. */
14:07 jnthn MVM_CF_FRAME = 4,
14:07 jnthn A callframe won't have a REPR
14:07 jnthn That debug output is making a bad assumption that everything is an object
14:07 jnthn Which it ain't
14:08 jnthn Might also be a MVMFrame or an MVMSTable
14:08 jnthn So I think the data is fine, the debug output is rotten
14:08 dogbert2 ok, cool
14:08 dogbert2 it only happens when I set MVM_GC_DEBUG_LOG_FLAGS = 2
14:10 dogbert2 perhaps I should comment out that line an see if things improve
14:10 dogbert2 *and
14:11 timotimo just guard it against REPR being null, that is acceptable
14:11 dogbert2 ok, I can do that
14:11 jnthn But it might be junk
14:12 jnthn There's no STable pointer you can use to reach REPR, even
14:12 jnthn It's only luck that we don't segv at that point
14:12 timotimo oh, how come REPR(item) gives 0x0 rather than access error? hm.
14:13 dogbert2 looks as if line #328 is suspect as well, it does the same thing, i.e. REPR(item)->ID ...
14:14 dogbert2 perhaps it would be possible to check if item->flags contains to something other than an MVMFrame or MVMSTable
14:15 timotimo yeah, that's probably easier
14:15 timotimo maybe write a short function that gives you either the repr id (or better: name) or something like "not an object" if it's a frame or stable
14:15 timotimo and re-use that for the debug logs everywhere
14:16 jnthn timotimo: Probalby 'cus some pointer lines up and we read it
14:16 timotimo ah, could very well be
14:19 dogbert2 hmm, now it crashes on line #265 instead, grr
14:19 dogbert2 printf("%d", ((MVMCollectable *)1)->owner);
14:21 dogbert2 heh, don't understand what that line does
14:22 timotimo what. 1?
14:22 timotimo that's quite certainly wrong
14:22 dogbert2 https://github.com/MoarVM/MoarVM/blob/master/src/gc/collect.c#L265
14:23 dogbert2 it does indeed look strange
14:23 timotimo no clue what purpose that had; maybe it was just never actually reached when the gc debug was still being tested?
14:23 timotimo i personally have not turned on the gc debug log more than once in my moarvm development life
14:24 dogbert2 I noticed the flag yesterday an wanted to see if it was something interesting
14:25 dogbert2 perhaps the functionality hasn't been used for a while
14:25 MasterDuke if anyone wants another problem to ponder on, https://irclog.perlgeek.de/moarvm/2018-01-02#i_15644397
14:26 timotimo MasterDuke: are there any interesting perl6-level backtraces for those cases?
14:26 MasterDuke well, i was running nqp's t/hll/06-sprintf.t
14:30 MasterDuke but and hadn't tried, but let me do that
14:33 MasterDuke https://gist.github.com/MasterDuke17/da472dfe4d1d48c78043b5ac40c2a7d6
14:34 timotimo we can just "do nothing" if the pointer is null for now
14:36 MasterDuke yeah, that's what i'm doing in my branch now
14:36 MasterDuke was experimenting with doing something better/smarter
14:37 MasterDuke i added fprintfs in fixed_size_alloc and fixed_size_realloc, nothing is asking for 0 bytes
14:38 timotimo perhaps we've freed a pointer, thus nulling it, and nulled the size along with it, but are now trying to free it a second tmie
14:38 MasterDuke any way to detect/track that?
14:49 dogbert2 I was hoping to use the GC_DEBUG logging in order to acquire more information wrt https://github.com/rakudo/rakudo/issues/1202
14:53 dogbert2 the orchestration output looks a bit suspect, at least to my untrained eye
14:54 dogbert2 when the code in the issue hangs it seems as if we're waiting for a thread which no longer exist
14:56 dogbert2 so we have, at the start of a GC run:
14:56 dogbert2 Thread 7 run 4 : GC thread elected coordinator: starting gc seq 4
14:56 dogbert2 Thread 7 run 4 : Signalled thread 10 to interrupt
14:57 dogbert2 that's the last we see of thread 10 in the output, breaking into gdb shows that threads 1..9 exist
14:57 timotimo it's probably a different counting method than what gdb uses
14:58 dogbert2 timotimo: you might very well be correct :(
14:58 dogbert2 but assuming that you're correct I would like to see lines like this but referring to thread 10
14:58 dogbert2 Thread 3 run 4 : Entered from interrupt
14:58 dogbert2 Thread 3 run 4 : Waiting for other threads
14:59 MasterDuke whoa, narrowly avoided an ENOCOFFEE error. almost poured the splash of half-and-half on top of the grounds in the grinder waiting to be brewed instead of in the mug
15:00 dogbert2 looking at succesful GC runs it seems that threads which have been signalled to interrupt should print lines like the above two but it doesn't happen and the code hangs
15:02 dogbert2 there's of course the, not insignificant, chance that I'm totally wrong about this
15:15 timotimo there's the possibility that the threads have marked themselves unable
15:15 timotimo in that case they don't signal, because they can't do anything on their own
15:19 dogbert2 what's supposed to happen then, should the GC proceed?
15:32 geospeck joined #moarvm
15:37 [Coke] I bet you could still use the beans at that point, just have a messy grinder to clean.
15:40 domidumont joined #moarvm
15:41 MasterDuke if they were still beans sure, but i'd just finished grinding them. i don't know, would grounds wet with half-and-half brew ok in a siphon coffee maker?
15:42 releasable6 joined #moarvm
15:44 [Coke] If you already *had* coffee, might be an interesting experiment. I also would not risk the first cup of the day, though. :)
15:46 ZofBot joined #moarvm
16:16 timotimo dogbert2: check the short description of GC_STATUS at the top of threadcontext.h
16:50 _Kaiepi joined #moarvm
16:51 geospeck joined #moarvm
16:58 squashable6 joined #moarvm
17:22 bloatable6 joined #moarvm
17:22 coverable6 joined #moarvm
17:22 benchable6 joined #moarvm
17:34 AlexDaniel joined #moarvm
17:39 bisectable6 joined #moarvm
17:55 domidumont joined #moarvm
18:06 AlexDaniel squashable6: next
18:06 squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 1 day and ≈15 hours (2018-01-06 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day
18:10 dogbert17 timotimo: tested again, here are the GC_STATUSES'es for the threads when the code hangs: t1 => 3, t2 => 1, t3 => 3, t4 => 3, t5 => 1, t6 => 1, t7 => 0, t8 => 3, t9 => 3, t10 => 1
18:11 timotimo those that are 3 were "unable" and got "stolen"
18:12 timotimo those that are 1 should be doing GC together
18:14 Lurieh__508 joined #moarvm
18:14 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSbcnnrdk: bloatable6 Voldenet bisectable6 ▄▄▄▄▄▄▄▄▄▄▄▄
18:14 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSutcbb: ilbot3 bisectable6 nwc10 ▄▄▄▄▄▄▄▄▄▄▄▄
18:15 Lurieh__508 â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSlsccvdend: camelia geekosaur Geth â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â
18:15 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSuoynrrczug: bisectable6 harrow nativecallable6 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄,
18:15 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSzsxnqlbewn: bloatable6 lizmat Voldenet ▄▄▄▄▄▄▄▄▄▄
18:15 [Coke] *sigh*
18:15 nwc10 joined #moarvm
18:15 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSjksroxzb: leedo greppable6 bartolin ▄▄▄▄▄▄▄▄▄▄▄▄
18:15 timotimo imagine blasting a spam message to thousands of users asking them to join a channel, then forgetting to put the channel name in
18:15 Lurieh__508 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSptolin: benchable6 ZofBot Voldenet ▄▄▄▄▄▄▄▄▄▄▄▄▄▄
18:15 Lurieh__508 â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„ A BUSY MEETING IS GOING ON NOW IN #/JOIN ITS A JOINT MEETING WITH THE DISCUSSION OF RE-ENSLAVEMENT OF NIGGERS..MESSAGE CHRONO OR VAP0R FOR DETAILSmxwgelm: bloatable6 nine ggoebel â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–
18:16 [Coke] I am not a channel operator, can't ban 'em.
18:16 * TimToady hates on haters
18:16 Voldenet I wonder if the one doing this really finds this a big problem
18:16 Voldenet for us to ignore this
18:17 * [Coke] imagines we could also do word bans for a bunch of stuff these bots are hitting.
18:17 timotimo TimToady: that makes you just as bad as them!
18:17 * TimToady also wonders what the effect on moarvm will be of https://www.pcworld.com/article/3245606/security/intel-x86-cpu-kernel-bug-faq-how-it-affects-pc-mac.html
18:17 dogbert17 timotimo: unfortunately the program does nothing, everyone seems to be waiting for something to happen
18:17 Voldenet no point, they'd just use some different words
18:18 [Coke] timotimo: we in the us may be a little sensitive about this sort of thing right now, but no, no it doesn't. :P
18:18 * dogbert17 has an AMD cpu
18:18 [Coke] Voldenet: ... fine. then we still miss a few hundred lines of crap.
18:19 [Coke] "we can't fix everything so do nothing" is not a great strategy. (also perhaps a US sensitivity atm.)
18:19 Voldenet TimToady: I believe syscalls will become more costly if I understand the implications of the patch
18:19 [Coke] how can I find out who the channel operators are?
18:19 [Coke] (aside from asking mst)
18:20 TimToady Voldenet: that is how I read it too
18:20 TimToady so we might wanna audit places where we do a lot of small syscalls to see if one larger one is available
18:21 Voldenet Welp, doing a lot of syscalls was never very optimal to begin with
18:22 TimToady yeah, I remember back in the day calculating that a single bsd system call was minimum 10,000 ops
18:22 TimToady or maybe I just heard it
18:22 TimToady that neuron is lost somewhere in mists
18:23 TimToady (that was ancient BSD on a Vax, so 10,000 instructions weren't so cheap...)
18:23 leont_ joined #moarvm
18:24 TimToady anyway, this is also a good argument for doing as much as possible with green threads rather than running every context switch through real threads
18:26 timotimo [Coke]: right, my message should have had a big fat /s at the end
18:26 TimToady well, there's something wrong with that, since the whole point of threads is to avoid context switches, but communication between real threads might have more syscalls, I suppose
18:26 nwc10 joined #moarvm
18:28 TimToady .oO(with enough hedges, any statement becomes true...)
18:28 TimToady .oO(mebbe)
18:28 timotimo dogbert17: maybe find the ones that are waiting on some kind of lock and see which one they each want. not sure how to figure out what other locks a thread is holding, though the lock ought to have stored which thread is currently holding it maybe
18:30 * hoelzro waves
18:31 hoelzro no one happens to have an irssi script that blocks messages mentioning a bunch of participants in the channel, do they? =)
18:36 timotimo oh it's a hoelzro :)
18:37 hoelzro hi timotimo!
18:39 timotimo coming back to the six per chance? :)
18:40 hoelzro I think about it sometimes - I miss it
18:41 hoelzro ever since I bought my house and got my dog, it feels like free time has shriveled up
18:44 Voldenet hoelzro: if you don't mind using weechat, there's https://weechat.org/scripts/source/mass_hl_blocker.pl.html/
18:45 hoelzro I haven't made the switch, but I could always adapt that script - thanks Voldenet!
19:00 FROGGS joined #moarvm
19:07 unicodable6 joined #moarvm
19:39 greppable6 joined #moarvm
20:59 evalable6 joined #moarvm
21:38 _Kaiepi joined #moarvm
23:40 leont_ joined #moarvm
23:45 quotable6 joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary