github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:39 dogbert11 left 04:28 statisfiable6 left, reportable6 left, benchable6 left, greppable6 left, squashable6 left, unicodable6 left, notable6 left, quotable6 left, committable6 left, bisectable6 left, releasable6 left, tellable6 left, bloatable6 left, coverable6 left, shareable6 left, evalable6 left, nativecallable6 left 04:29 reportable6 joined, statisfiable6 joined, committable6 joined, coverable6 joined, notable6 joined 04:30 shareable6 joined, nativecallable6 joined, bisectable6 joined, quotable6 joined 04:31 unicodable6 joined, tellable6 joined 04:32 squashable6 joined, benchable6 joined, releasable6 joined 04:33 greppable6 joined, evalable6 joined, bloatable6 joined 05:19 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 06:27 domidumont joined 06:32 domidumont left 06:47 domidumont joined 07:56 zakharyas joined 08:06 zakharyas left 08:07 zakharyas joined 08:08 brrt joined
brrt \o 08:55
nwc10 o/ 08:56
08:57 sena_kun joined 09:07 zakharyas left
brrt ohai nwc10 09:07
brrt realized that it's a good thing we didn't call moarvm perl6vm
jnthn :) 09:22
Yeah, I'm glad Cro and Comma got names that don't pun on Perl 6 too. 09:23
I dunno what to do with 6guts :) 09:24
AlexDaniel as if renaming something once is worse than having a cryptic name
jnthn But I'm so awful at ever blogging anyway...
AlexDaniel: I think perl6vm might have been less cryptic... :-) 09:25
Generally, though, we tried to avoid naming things by the language name unless they were reasonably "the only one"
AlexDaniel jnthn: that's my point, the fact that it's not ā€œperl6vmā€ is not strictly a good thing 09:26
09:27 zakharyas joined
jnthn AlexDaniel: Well, you'll just have to live with it. 09:27
09:28 brrt left
nine notes that while the rename has been the dominant topic for several weeks, it's just one of many. Hope that people don't lose sight of all the interesting and fun things that brought us together 09:29
jnthn Indeed, and having fun with naming is as Perl-y a thing as any, really. :) 09:31
AlexDaniel naming things the way we do never really did enough good for us, and I'll do my best to at least stop introduction of new cryptic names 09:34
it's part of the culture though, that I agree with 09:35
doesn't really mean it's a good part
jnthn Sadly, there's not much joy in trying to stop people sucking the joy out of things... I hope at some point soon, I'll be able to get back to enjoying what I do around here again. 09:43
Guest23744 jnthn: why not dive into some some cool hacking for a while? 09:59
10:10 domidumont left 10:19 zakharyas left
nine Guest23744: I guess because he has taken on the burden of leadership and this can really suck you dry and just not leave the energy even to take up fun things. Carrying responsibility and having to make decisions for others without being able to delegate them can be really exhausting. 11:00
Guest23744 nine: I can imagine 12:16
nine: have you found any more GC/fromspace problems? 12:18
I'm having a hard time finding any myself 12:20
12:23 ggoebel joined
nine Well, there's the one I was discussing with jnthn that still needs a proper fix and I guess the async IO thing you pointed out is still unsolved? 12:26
Guest23744 Yes, I guess I could PR that one but I need to learn some things (from you first) :)
nine Please go on :) 12:27
Guest23744 here's the area in the code 12:28
github.com/MoarVM/MoarVM/blob/mast...ops.c#L496
the mutex can be busted in line 500 because close_stdin can allocate
so what should be rooted, os_handle or something else? 12:29
or could it perhaps be enough to move some stuff around thereby avoiding having to root anything 12:30
ggoebel jnthn: fwiw I always enjoy your blog posts. and wrt to people sucking the joy out of things... Sometimes (particularly when people have a tendency to focus on problems more than solutions) it is hard to remember that everyone is the protagonist of their own story. You all do a good job of keeping things civil and leading positively by example. Don't sweat the things you can't control. Finding you're own -Ofun joy is infectious. 12:33
nine You could indeed pull the pointer to the mutex into a local variable. The mutex itself won't change location
12:37 domidumont joined 12:39 lucasb joined
nine Now that I think about it: it would be hilarious if this were to fix the issue that still remains in t/02-rakudo/15-gh_1202.t when the resolve_using_guards issue is gone 12:43
Guest23744 nine: I can try and whip something together when I get home unless you want to do it 12:48
13:14 zakharyas joined
ggoebel wrt the renaming... Everyone has had a chance to be heard. The process has been as open transparent, and fair as could reasonably be hoped. A couple reviewers still outstanding... When the chips fall as they likely will on going forward with it... Hopefully everyone will get behind and make the best of the opportunity. In the end a name is just an identifier. And Raku by any name is -Ofun. "A rose by any other name would smell as 13:19
sweet".
nine Oooh...sometimes it's really a good idea to first look at a failing test: Promise.in(600), # 10mins timeout 14:03
No wonder this fails
14:25 zakharyas left 15:16 zakharyas joined, MasterDuke joined
MasterDuke jnthn: are the last couple comments in github.com/MoarVM/MoarVM/issues/1023 useful? 15:25
jnthn The Aug 18th one is most telling... 15:29
(There's profiler-related code on the stack)
While the others just have the GC
MasterDuke ok, glad there's something useful there 15:31
jnthn Yeah, there's various nuggets in the issue. Hmm. 15:32
MasterDuke fwiw, none the (many) fixes in the past couple months have seemed to change any of the behavior with that example 15:41
nine The MVM_gc_allocate_gen2_default_set + clear in MVM_profile_dump_instrumented_data's while (thread) loop seems superfluous
MasterDuke nine: the example code does not seem to like it if i remove those lines 15:49
spins in a sched_yield before it gets to the point of saying `Writing profiler output to ...` 15:50
jnthn: also, i just got a segv (without having made any changes) even with `MVM_SPESH_INLINE_DISABLE=1` 15:51
tiny backtrace: #0 0x000055556dd44190 in ?? ()#1 0x00007ffff78ddeb6 in MVM_interp_run (tc=tc@entry=0x555555559f40, initial_invoke=0x55556d5c5c70, initial_invoke@entry=0x7ffff79db9a0 <toplevel_initial_invoke>, invoke_data=0x55556d5c5c70, invoke_data@entry=0x7ffff79db9a0 <toplevel_initial_invoke>) at src/core/interp.c:2213#2 0x00007ffff79dca2f 15:52
in MVM_vm_run_file (instance=<optimized out>, filename=0x5555555593f0 "/home/dan/Source/perl6/install/share/perl6/runtime/perl6.moarvm") at src/moar.c:460#3 0x00005555555555d4 in main (argc=<optimized out>, argv=<optimized out>) at src/vm/moar/runner/main.c:369
15:53 dogbert11 joined
jnthn Hm, with JIT enabled, I figure? 15:53
MasterDuke uh, maybe? i thought turning off any part of spesh also disabled the jit? 15:55
nine no 15:57
15:57 dogbert11 left
MasterDuke then yes, jit was enabled 15:58
hm, with `MVM_SPESH_INLINE_DISABLE=1 MVM_JIT_DISABLE=1` it's run successfully for a bunch of times now 16:03
16:06 zakharyas left 16:19 dogbert17 joined
jnthn MasterDuke: Ah, that explains the ?? in the top of the stack trace then 16:29
MasterDuke disabling PEA or OSR and the jit gives the same errors as before 16:31
jnthn So, it's a plain profiler bug, probably unaffected by spesh/jit? 16:34
MasterDuke probably. the code that's running is compiling regexes, so i would assume it's related to EVAL 16:38
i.e., interpolating into regexes 16:39
jnthn ah, hmm...maybe GC of code upsets it 16:40
16:41 domidumont left
MasterDuke think GC_DEBUG would help? 16:41
jnthn A straight `perl6 --profile -e 'for ^100_000 { EVAL "42" }'` doesn't seem to be blowing up though
urgh, leaks like hell though 16:42
Well, maybe that's not surprising if it's gathering profile data of every single comp unit...
But hmm, it leaks even without `--profile`
Well, maybe next week I'll have a dig... 16:43
MasterDuke `p6 --profile -e 'my $a; for ^100_000 { $a = rand ~~ /<$_>/; }'` gives panics and segvs
jnthn oh :)
Nice golf
MasterDuke i do also have a spectest running 16:44
jnthn Though, it did neither here for me just yet
Though I'm running without any GC stressing etc.
MasterDuke sometimes it just seems to hang without doing anything 16:45
with perf top showing MVM_profile_instrumented_mark_data in 2nd place 16:46
huh. this is new (during a run of that golf): ===SORRY!===Unrecognized regex metacharacter - (must be quoted to match literally)at /home/dan/EVAL_151:1------> anon regex { 9.79300556114282eā-05}Malformed regexat /home/dan/EVAL_151:1------> anon regex { 9.79300556114282e-ā05} 16:48
here's another short one with just the jit disabled. end's up in sp_guardcond. gist.github.com/MasterDuke17/9b15e...a73507fbe4 16:54
dogbert17 MasterDuke: with MVM_GC_DEBUG=1 nine's favorite problem crops up
MoarVM panic: Adding pointer 0xf7a2d8 to past fromspace to GC worklist
MasterDuke dogbert17: in the golf from above? 16:55
dogbert17 yes
MasterDuke you don't need GC_DEBUG to get that though
jnthn $ perl6 --profile -e 'my $a; for ^100_000 { $a = rand ~~ /<$_>/; } 16:56
'
MoarVM panic: Adding pointer 0x1aeaba8 to past fromspace to GC worklist
That's with GC debug on and small nursery
MasterDuke i get lots of "Internal error: zeroed target thread ID in work pass"
with everything stock, but jit disabled
jnthn (gdb) where 16:58
#0 MVM_panic (exitCode=1, messageFormat=0x7ffff79e3e68 "Adding pointer %p to past fromspace to GC worklist") at src/core/exceptions.c:832
#1 0x00007ffff75b2ef4 in mark_call_graph_node (tc=0x603cc0, node=0x65ef5c0, nodelist=0x7fffffffba90, worklist=0x65a4150) at src/profiler/instrument.c:830
That's `MVM_gc_worklist_add(tc, worklist, &(node->alloc[i].type));`
Curiously, the thing that sets it actually does MVM_ASSERT_NOT_FROMSPACE(tc, what); 17:02
Where `what` is what it installs
MasterDuke without actually knowing what that does...it still sounds wrong 17:03
jnthn Well, it checks that the pointer isn't outdated at the point we stick it into the data structure
And then we walk the profile data structure every time that we do a GC 17:04
So I'm not quite seeing where we'd end up with the bogus pointer
MasterDuke so it gets outdated after the MVM_ASSERT call?
jnthn Presumably, yes. But we run the code to walk the nodes every GC
So, maybe there's a bug in that walk code?
MasterDuke this is a (sort of) new one: `MoarVM panic: Heap corruption detected: pointer 0xdcb3370 to past fromspace` 17:05
this sounds like a job for supernine 17:06
jnthn Well, add_node is complex enough that it could have a bug lurking 17:08
It's being clever, but is it being too clever? :) 17:09
(I'm too tired to figure it out right now, but I'd take a close look at it.)
MasterDuke thanks for the help so far, maybe timotimo or nine can make progress if they get to it before you 17:11
btw, i just noticed add_node does a *= 2 when it reallocs. wasn't there someone recently commenting (i don't remember where) that that's a bad value? 17:15
Kaiepi jnthn can github.com/MoarVM/MoarVM/pull/1166 be merged on monday? brrt reviewed it
jnthn Kaiepi: Will try and take a look over the weekend; I've a couple of PRs I want to look through 17:21
Kaiepi ok 17:22
there was one minor change i wanted to make to it after merging but ig i could do it now if i have the time 17:24
jnthn goes for dinner
17:26 patrickb joined
patrickb May I ask for a pair of eyes on github.com/MoarVM/MoarVM/pull/1182 ? I'd like to have that merged before the next release, as I see it as a prerequisite for a binary release on Windows. 17:27
have to leave again... 17:28
17:28 patrickb left 17:44 robertle joined
nine I think I'm going to turn the whole SpeshPluginState into an MVMCollectable, not just the guard set. 18:17
18:38 MasterDuke left 18:50 MasterDuke joined
nine Ooook....compiler's happy 18:55
18:55 zakharyas joined
dogbert17 nine: might this work? gist.github.com/dogbert17/4180fe5c...a73c091df0 18:56
nine dogbert17: it's what I'd do
MasterDuke nine: what error are you fixing? 18:58
dogbert17 the, previously, affected test has been running for over an hour without crashing. Before it crashed within a minute or so (using a 32k nursery)
nine MasterDuke: the multi threaded GC spesh plugin issue my commit from yesterday was about where timotimo++ immediately spotted an additional problem 19:00
MasterDuke nice
19:08 MasterDuke left
dogbert17 nine: does this commit message make sense or is it total nonsense? 19:21
github.com/MoarVM/MoarVM/compare/m...s?expand=1
nine dogbert17: makes sense 19:23
dogbert17 cool, PR coming up soonish 19:24
Geth_ MoarVM: dogbert17++ created pull request #1183:
Fix possible SEGV in async_spawn_on_exit		 19:26
dogbert17 had to complete a spectest run, which was clean btw
.seen timotimo 19:27
tellable6 dogbert17, I saw timotimo 2019-09-27T12:27:59Z in #perl6: <timotimo> ah, yes, indeed
Geth_ MoarVM: 5dfed00877 | (Jan-Olof Hendig)++ | src/io/procops.c
Fix possible SEGV in async_spawn_on_exit

If a GC is triggered by the call to close_stdin, which can allocate, the os_handle pointer will no longer point to to the mutex being used a few lines above, leading to a SEGV. Fixed by saving the pointer to the mutex in a local variable. This is ok since the mutex itself will not move.		 19:31
MoarVM: 1546c8c4d4 | niner++ (committed using GitHub Web editor) | src/io/procops.c
Merge pull request #1183 from dogbert17/fix-segv-in-procops

Fix possible SEGV in async_spawn_on_exit
nine dogbert17: feels good, doesn't it? :) 19:32
dogbert17 nine: indeed :) but now we're almost out of gc related bugs 19:33
nine Well...the profiler seems to harbor some still: github.com/MoarVM/MoarVM/issues/1023 19:34
dogbert17 however, MasterDuke managed to golf one an hour or so ago
backlog a little bit until you se the discussion with jnthn
*see
19:41 zakharyas left 20:07 sena_kun left 20:08 sena_kun joined 20:15 sena_kun left
Kaiepi what should i name a list of addresses returned by getaddrinfo and the current address being used? atm they're called dest and record, but that doesn't make it obvious that they're related at first glance 20:36
would records and cur_record work? 20:37
moritz what is the "current address"? 21:06
Kaiepi the next address to connect or bind with 21:08
or write with for udp sockets 21:09
moritz so, like a linked list?
Kaiepi yes 21:12
moritz then your suggested names sound good 21:14
Kaiepi aight 21:20
22:12 ggoebel left 22:38 lucasb left 23:06 ggoebel joined 23:35 ggoebel left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!