github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:12
patrickz joined
00:17
patrickb left,
lucasb left
00:49
patrickz left
01:02
sena_kun left
01:15
sena_kun joined
01:19
sena_kun left
01:51
greppable6 left
02:05
greppable6 joined
06:33
robertle left,
sena_kun joined
07:01
sena_kun left
08:52
zakharyas joined
08:59
domidumont joined
10:00
domidumont left
10:08
domidumont joined
12:17
zakharyas left
12:37
lucasb joined
14:04
zakharyas joined
14:22
sena_kun joined
14:34
zakharyas left
14:36
zakharyas joined
14:41
sena_kun left
15:22
zakharyas left
15:23
zakharyas joined
16:07
squashable6 left
16:10
squashable6 joined
|
|||
Kaiepi | is this ok to merge now? github.com/MoarVM/MoarVM/pull/1214 | 16:33 | |
nine? | 16:36 | ||
16:43
domidumont left
16:54
AlexDani` joined
16:55
zakharyas left
16:56
AlexDaniel left
|
|||
nine | Kaiepi: will have a look later on. Have to teach now | 16:57 | |
17:03
domidumont joined
|
|||
Kaiepi | aight, thanks | 17:26 | |
17:31
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined
|
|||
lizmat | And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2019/12/02/2019-...ed-advent/ | 17:49 | |
18:01
sena_kun joined
|
|||
dogbert17 | nine, jnthn: does this SEGV look familiar? gist.github.com/dogbert17/bb53b675...abbbc337fc | 18:46 | |
19:02
sena_kun left
19:19
sena_kun joined
19:54
lizmat_ joined
19:56
xiaomiao joined
|
|||
nine | dogbert17: no, and it's hard to imaginge how this could fail | 20:01 | |
20:02
lizmat left,
releasable6 left,
notable6 left,
bisectable6 left,
evalable6 left,
DrEeevil left
|
|||
dogbert17 | nine: haven't been able to repro it either | 20:03 | |
nine | too bad | 20:04 | |
dogbert17 | that's three obscure SEGV's in the last two days | 20:05 | |
nine | Only makes sense to me if the stats were free()d in the meantime | ||
dogbert17 | I hardly dare ask, but can it have anything to do with recent fixes in this area? | 20:07 | |
nine | Sure. There's one by jnthn++ and a couple by me. | 20:12 | |
dogbert17 | the annoying thing is that these crashes are annoyingly random and all attempts to repro fails :( | 20:16 | |
nine | Kaiepi: can you please squash "Improve UNIX socket path error message, e => error" into "Clean up MVM_io_resolve_host_name and make it more portable"? | 20:32 | |
MasterDuke | dogbert17: have you seen anything odd with t/spec/S03-operators/repeat.t? on random runs i get a bunch of output like `Use of uninitialized value element of type Any in string context.Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful. in sub throws-like at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) | 20:34 | |
line 605WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:Cannot convert NaN to Int: in block at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line 614 in sub subtest at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line | |||
420 in sub throws-like at /home/dan/Source/perl6/rakudo/lib/Test.pm6 (Test) line 606 in block <unit> at t/spec/S03-operators/repeat.t line 27` | |||
i once i had a segv in the middle of a spectest run, but i haven't been able to repro | 20:35 | ||
Kaiepi | nine, done | 20:37 | |
dogbert17 | MasterDuke: yes, I see the same things if I run that file | 20:43 | |
MasterDuke | huh | 20:45 | |
nine | Also annoying: there's a segfault in an Inline::Perl5 test that only appears on a 32 bit runtime. I just managed to reproduce some segfault on 64 bit with MVM_SPESH_NODELAY and MVM_SPESH_BLOCKING, but I ony get a broken backtrace :/ | 20:48 | |
20:51
bisectable6 joined,
notable6 joined
20:53
releasable6 joined
20:54
evalable6 joined
|
|||
nine | Nevertheless I could actually find out where it crashes by going through the spesh threads's tc: p *tc->instance->threads->body.next->body.tc->cur_frame->static_info->body.name | 20:59 | |
MasterDuke | anything interesting? | 21:00 | |
21:02
sena_kun left
|
|||
samcv | good * | 21:02 | |
Geth | MoarVM: 0074094c21 | (Ben Davies)++ | src/io/syncsocket.c Clean up the comment for MVM_io_resolve_host_name |
21:03 | |
MoarVM: cd64bf94c4 | (Ben Davies)++ | src/io/syncsocket.c Clean up MVM_io_resolve_host_name and make it more portable UNIX socket addresses were being handled in a way that would only work properly on Linux. Handle paths in a more portable way, and when the platform used probably doesn't support UNIX sockets, say so. |
|||
MoarVM: 34813e1813 | niner++ (committed using GitHub Web editor) | src/io/syncsocket.c Merge pull request #1214 from Kaiepi/dns [IP6NS Grant] Clean up and make MVM_io_resolve_host_name more portable |
|||
nine | MasterDuke: maybe. It seems to fail in a call to a different function than in the 32 bit fail. | 21:05 | |
MasterDuke | vrurg: you know git submodules. what are the magic incantation i should make to create a PR updating MoarMV's 3rdparty/libtommath to the upstream recent v1.2 release? | 21:08 | |
dogbert17 | I can't even run the tests, from a cloned repo, that comes with Inline::Perl5, I get this: | 21:14 | |
ype check failed in binding to parameter '$library'; expected IO::Path but got Slip (Empty) | 21:15 | ||
in sub guess_library_name at /home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/core/sources/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B (NativeCall) line 214 | |||
nine | huh? | ||
dogbert17 | I cloned Inline::Perl5 and ran 'perl6 -Ilib t/argv.t' | 21:16 | |
nine | dogbert17: did you run configure.pl6 first? | ||
MasterDuke: different called function but actually the same failure mode! | |||
samcv | MasterDuke, well that is MoarVM/libtommath. so you would want to cd into 3rdparty/libtommath and then `git remote add upstream $libtommath-upstream-url`. `git fetch upstream master`, then `git merge upstream/master` | 21:17 | |
then hopefully there are no merge conflicts | |||
21:17
sena_kun joined
|
|||
nine | Oh, and disabling spesh makes the issue disappear on i586, giving further indication that it's indeed the same issue. Which means that I can reproduce it now in my normal dev environment :) | 21:18 | |
dogbert17 | nine: nope, I was too stupid so I ignored the README.md :( | ||
it works now, which test is failing with a segv (have a 32 bit vm) | 21:19 | ||
nine | t/from.t | ||
dogbert17 | cool | ||
ran it a few times without any problems | 21:21 | ||
nine | Of course now the question is: how can spesh cause this issue? | 21:22 | |
dogbert17 | ha, now it failed when I built the latest version | 21:29 | |
it worked without a hitch on 'This is Rakudo version 2019.11-53-g1945b9d27 built on MoarVM version 2019.07.1-322-g8d0b50d3f' | |||
nine | Yeah, it's probably my NativeCall fix | 21:32 | |
21:34
domidumont left
|
|||
dogbert17 | I'm building the previous rakudo version, c16b5a204fea5b3a3bb74b0ceea1ba1b907e9365, atm to test that | 21:34 | |
and on that version the test passes | 21:43 | ||
nine | Well...I'll have another look tomorrow | 21:49 | |
MasterDuke | samcv: i believe their new version incorporates or makes obe all our changes. i've fetched and then checked out their v1.2.0 and moarvm/nqp/rakudo all build and pass tests | 22:18 | |
22:46
lizmat_ is now known as lizmat
22:47
lucasb left
|
|||
samcv | MasterDuke, well then i'd check out our version, do `git merge` like i said above. then do `git diff upstream-version`. then apply that changeset on top of the merge commit | 22:51 | |
`git diff > diffs && patch -p1 diffs && git add -u && git commit` | 22:52 | ||
23:02
sena_kun left
|
|||
MasterDuke | hm. but wouldn't it make more sense to use upstream unmodified? i.e., instead of the steps you mention, just make a clean break so we don't have different commit ids from upstream? | 23:05 | |
23:16
sena_kun joined
|