00:06 lizmat joined 00:22 geekosaur joined 01:31 geekosaur joined 02:16 FROGGS_ joined 02:36 Kaiepi joined 02:59 ilbot3 joined 03:16 Kaiepi joined 03:21 Kaiepi joined 06:23 geospeck joined 07:15 FROGGS joined 08:13 gfldex joined 08:20 andrzejku joined 09:04 zakharyas joined 09:11 leont_ joined 09:17 gfldex left 09:24 domidumont joined 09:31 domidumont joined 09:35 committable6 joined 09:56 leont_ joined 11:44 domidumont joined 12:02 reportable6 joined 12:08 MasterDuke joined
dogbert2 jnthn: have you recovered from your nasty flu yet? 12:10
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: github.com/rakudo/rakudo/commit/fc...4ccc2R1599 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 13:09 statisfiable6 joined 13:11 nativecallable6 joined
dogbert2 jnthn: sounds promising. Let me know when you're fresh enough to try to answer a question :) 13:28
.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
timotimo o/ 13:49
dogbert2 o/ do you have time for a question regarding a SEGV?
timotimo i can give it a try
dogbert2 this line: github.com/MoarVM/MoarVM/blob/mast...ect.c#L315 13:50
'item' points to an MVMCollectible-something but REPR(item) becomes null 13:51
what could cause that to happen, any ideas?
that's question number one :) 13:52
timotimo ah, that one
dogbert2 :-)
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
but that access is going to the copy source, not the destination, right?
dogbert2 I believe so. I don't know what REPR does though
I get this when enabling COLLECTION messages in orchestrate.h 13:54
which leads me to question no 2 13:55
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
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, ...
dogbert2 could the object, i.e. item be corrupt then since the REPR call returns null
timotimo maybe have a closer look at the STABLE(foo) first 13:57
dogbert2 that can be arranged :) but first another question :)
if you check github.com/MoarVM/MoarVM/blob/mast...ect.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:58
doesn't that mean that line 315 is always executed 13:59
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?
or is the compiler smarter than that 14:01
ok, now I'm in gdb after the SEGV, i.e. at 14:04
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",
gdb) p item
$1 = (MVMCollectable *) 0xb74eb4c8
(gdb) p REPR(item) 14:05
$2 = (const MVMREPROps *) 0x0
jnthn p *item ? 14:06
Or more interesting maybe
p item->flags
dogbert2 (gdb) p *item
$3 = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, sci = 0x0, st = 0x0}, owner = 1, flags = 4, size = 112}
jnthn /* Is a heap-promoted call frame. */ 14:07
MVM_CF_FRAME = 4,
A callframe won't have a REPR
That debug output is making a bad assumption that everything is an object
Which it ain't
Might also be a MVMFrame or an MVMSTable 14:08
So I think the data is fine, the debug output is rotten
dogbert2 ok, cool
it only happens when I set MVM_GC_DEBUG_LOG_FLAGS = 2
perhaps I should comment out that line an see if things improve 14:10
*and
timotimo just guard it against REPR being null, that is acceptable 14:11
dogbert2 ok, I can do that
jnthn But it might be junk
There's no STable pointer you can use to reach REPR, even 14:12
It's only luck that we don't segv at that point
timotimo oh, how come REPR(item) gives 0x0 rather than access error? hm.
dogbert2 looks as if line #328 is suspect as well, it does the same thing, i.e. REPR(item)->ID ... 14:13
perhaps it would be possible to check if item->flags contains to something other than an MVMFrame or MVMSTable 14:14
timotimo yeah, that's probably easier 14:15
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
and re-use that for the debug logs everywhere
jnthn timotimo: Probalby 'cus some pointer lines up and we read it 14:16
timotimo ah, could very well be
dogbert2 hmm, now it crashes on line #265 instead, grr 14:19
printf("%d", ((MVMCollectable *)1)->owner);
heh, don't understand what that line does 14:21
timotimo what. 1? 14:22
that's quite certainly wrong
dogbert2 github.com/MoarVM/MoarVM/blob/mast...ect.c#L265
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?
i personally have not turned on the gc debug log more than once in my moarvm development life
dogbert2 I noticed the flag yesterday an wanted to see if it was something interesting 14:24
perhaps the functionality hasn't been used for a while 14:25
MasterDuke if anyone wants another problem to ponder on, irclog.perlgeek.de/moarvm/2018-01-02#i_15644397
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
but and hadn't tried, but let me do that 14:30
gist.github.com/MasterDuke17/da472...ac40c2a7d6 14:33
timotimo we can just "do nothing" if the pointer is null for now 14:34
MasterDuke yeah, that's what i'm doing in my branch now 14:36
was experimenting with doing something better/smarter
i added fprintfs in fixed_size_alloc and fixed_size_realloc, nothing is asking for 0 bytes 14:37
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?
dogbert2 I was hoping to use the GC_DEBUG logging in order to acquire more information wrt github.com/rakudo/rakudo/issues/1202 14:49
the orchestration output looks a bit suspect, at least to my untrained eye 14:53
when the code in the issue hangs it seems as if we're waiting for a thread which no longer exist 14:54
so we have, at the start of a GC run: 14:56
Thread 7 run 4 : GC thread elected coordinator: starting gc seq 4
Thread 7 run 4 : Signalled thread 10 to interrupt
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
dogbert2 timotimo: you might very well be correct :( 14:58
but assuming that you're correct I would like to see lines like this but referring to thread 10
Thread 3 run 4 : Entered from interrupt
Thread 3 run 4 : Waiting for other threads
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 14:59
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:00
there's of course the, not insignificant, chance that I'm totally wrong about this 15:02
timotimo there's the possibility that the threads have marked themselves unable 15:15
in that case they don't signal, because they can't do anything on their own
dogbert2 what's supposed to happen then, should the GC proceed? 15:19
15:32 geospeck joined
[Coke] I bet you could still use the beans at that point, just have a messy grinder to clean. 15:37
15:40 domidumont joined
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:41
15:42 releasable6 joined
[Coke] If you already *had* coffee, might be an interesting experiment. I also would not risk the first cup of the day, though. :) 15:44
15:46 ZofBot joined
timotimo dogbert2: check the short description of GC_STATUS at the top of threadcontext.h 16:16
16:50 _Kaiepi joined 16:51 geospeck joined 16:58 squashable6 joined 17:22 bloatable6 joined, coverable6 joined, benchable6 joined 17:34 AlexDaniel joined 17:39 bisectable6 joined 17:55 domidumont joined
AlexDaniel squashable6: next 18:06
squashable6 AlexDaniel, āš šŸ• Next SQUASHathon in 1 day and ā‰ˆ15 hours (2018-01-06 UTC-12āŒUTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
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:10
timotimo those that are 3 were "unable" and got "stolen" 18:11
those that are 1 should be doing GC together 18:12
18:14 Lurieh__508 joined
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
ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ 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 ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„
Ć¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€ž 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
ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ 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 ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„,
ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ 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 ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„
[Coke] *sigh*
18:15 nwc10 joined
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
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 ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„ā–„
Ć¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€ž 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 Ć¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“ā€žĆ¢ā€“
[Coke] I am not a channel operator, can't ban 'em. 18:16
TimToady hates on haters
Voldenet I wonder if the one doing this really finds this a big problem
for us to ignore this
[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!
TimToady also wonders what the effect on moarvm will be of www.pcworld.com/article/3245606/se...c-mac.html
dogbert17 timotimo: unfortunately the program does nothing, everyone seems to be waiting for something to happen
Voldenet no point, they'd just use some different words
[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
[Coke] Voldenet: ... fine. then we still miss a few hundred lines of crap.
"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
[Coke] how can I find out who the channel operators are?
(aside from asking mst)
TimToady Voldenet: that is how I read it too 18:20
so we might wanna audit places where we do a lot of small syscalls to see if one larger one is available
Voldenet Welp, doing a lot of syscalls was never very optimal to begin with 18:21
TimToady yeah, I remember back in the day calculating that a single bsd system call was minimum 10,000 ops 18:22
or maybe I just heard it
that neuron is lost somewhere in mists
(that was ancient BSD on a Vax, so 10,000 instructions weren't so cheap...) 18:23
18:23 leont_ joined
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:24
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
TimToady
.oO(with enough hedges, any statement becomes true...)
 18:28
.oO(mebbe)
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
hoelzro waves 18:30
no one happens to have an irssi script that blocks messages mentioning a bunch of participants in the channel, do they? =) 18:31
timotimo oh it's a hoelzro :) 18:36
hoelzro hi timotimo! 18:37
timotimo coming back to the six per chance? :) 18:39
hoelzro I think about it sometimes - I miss it 18:40
ever since I bought my house and got my dog, it feels like free time has shriveled up 18:41
Voldenet hoelzro: if you don't mind using weechat, there's weechat.org/scripts/source/mass_hl...r.pl.html/ 18:44
hoelzro I haven't made the switch, but I could always adapt that script - thanks Voldenet! 18:45
19:00 FROGGS joined 19:07 unicodable6 joined 19:39 greppable6 joined 20:59 evalable6 joined 21:38 _Kaiepi joined 23:40 leont_ joined 23:45 quotable6 joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!