Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:07 reportable6 left 01:07 linkable6 left, evalable6 left 01:35 frost joined 02:08 evalable6 joined 03:09 reportable6 joined 04:06 CaCode- joined 04:09 CaCode_ left, linkable6 joined 05:09 evalable6 left, linkable6 left 05:35 frost left 05:40 CaCode- left 06:09 reportable6 left 06:10 reportable6 joined
Nicholas * *, * 06:43
07:10 evalable6 joined 07:33 Altai-man joined 07:35 Altai-man left 08:03 CaCode joined 08:05 CaCode_ joined 08:09 CaCode left 08:37 frost joined
nine C11 atomics are still disabled by default, aren't they? 08:53
Nicholas yes. default is the old way 08:54
nine time to switch? 08:55
Nicholas I thought give it another release or so before 08:56
but tht was guesswork
nine I've got a request on the OBS to replace bundled libraries with system ones and it'd enable C11 atomics to get rid of libatomicops as well: build.opensuse.org/request/show/956564
My guess is: no one's gonna test it unless it's enabled by default. Even I, who was very positively exited about this forgot it until I worked on the ChangeLog for the updated openSUSE packages. 08:57
Nicholas My hope was: someone doing Linux stuff *would* enable it in their build config, and they'd find if there was fun. (I was assuming debian, actually) 08:58
MasterDuke a week or two ago i remembered to add it to my default build config and haven't had any problems, but that's just a single data point 09:29
09:29 frost left
Geth MoarVM: 1b8b2e39f4 | (Daniel Green)++ | 3rdparty/mimalloc
Bump mimalloc to v2.0.5
MoarVM: ec9fcaae2c | MasterDuke17++ (committed using GitHub Web editor) | 3rdparty/mimalloc
Merge pull request #1672 from MasterDuke17/bump_mimalloc_to_v2.0.5
10:09 frost joined 10:12 CaCode_ left
lizmat MasterDuke: feels to me we should get this to Rakudo also asap, right ? 10:49
MasterDuke yeah, guess so 10:50
nine "free(): invalid size" in normal Raku code sounds like a mimalloc issue, doesn't it? 10:52
MasterDuke likely 10:54
Nicholas at a guess, with zero context, it sounds like a C code bug where the wrong pointer is passed to free
lizmat nine: should I interprete your reaction as a veto to bump ? 10:57
10:58 discord-raku-bot left, discord-raku-bot joined 11:01 Altai-man joined
nine lizmat: no. We see those errors on 2022.02. I'm now disabling mimalloc in the moarvm opensuse package and test again with that 11:02
Nicholas nine: if you do it without mimalloc, does valgrind tell you anything "Exciting' 11:03
or a (slow) ASAN build?
lizmat ok, so I will do the bump! (cue disco music!)
nine Unfortunately I don't have time for a thorough investigation right now. 11:04
Building with --no-mimalloc seems to have fixed the issue 11:20
Nicholas or hidden it. Assuming this is glibc, what does setting MALLOC_PERTURB_=N MALLOC_CHECK_=2 11:26
and re-running do?
er, wait, I think it should be MALLOC_PERTURB_=42 MALLOC_CHECK_=2
or similar
MasterDuke actually, assuming the app is using nativecall, i think i see a bug 11:27
Nicholas `man mallopt`
MasterDuke github.com/MoarVM/MoarVM/blob/mast...#L800-L807 vs github.com/MoarVM/MoarVM/blob/mast...1301-L1304 11:28
same with libffi 11:30
nine No problem with MALLOC_PERTURB_=42 MALLOC_CHECK_=2 11:33
MasterDuke nine: is the code using nativecall?
nine yes 11:37
Geth MoarVM: MasterDuke17++ created pull request #1673:
Fix potential invalid free in nativecall
MasterDuke whoops, ^^^ is not (fully) correct 11:45
12:07 reportable6 left 12:09 reportable6 joined
MasterDuke i just tried to replace github.com/MoarVM/MoarVM/blob/mast...1089-L1099 with a call to MVM_nativecall_unmarshal_string(), but it expects to get an MVMObject and get the MVMString out of it `MVMString *value_str = MVM_repr_get_str(tc, value);` 12:18
nine Yeah, that's a different use case 12:19
MasterDuke yeah, changing `MVMString *value = args.source[args.map[i + 1]].s;` to get the `.o` causes `This representation (MVMString) cannot unbox to a native string (for type VMString)` 12:20
nine That's just the wrong approach 12:21
MasterDuke yeah, trying to decide if i should just add two parameters to MVM_nativecall_unmarshal_string, an MVMString * and a flag for whether to use that or the MVMObject 12:23
or whether that's too ugly and i should just inline more parts of MVM_nativecall_unmarshal_string, since it's already partially duplicated in those cases anyway 12:25
nine Just inline more
Sometimes code duplication is just the lesser evil
lizmat isn't that why you have C macros ? 12:26
or is that a bigger evil ?
nine MasterDuke: you could put the part starting with `char *str;` into a new MVM_nativecall_encode_string function and call that both from MVM_nativecall_unmarshal_string and MVM_nativecall_dispatch 12:29
lizmat fwiw, in the last 2 bumps I did to Raku, I needed to nuke ~/.raku/precomp to get things to work again :-( 12:38
Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'site#sources/45334C557865A97D1ECA0D3F3A3FAF2017FCE553 (OO::Monitors)')
I'm starting to wonder whether that shouldn't just be part of the rakudo install process 12:40
nine Came across the same thing today and had a quick look (before those 4 other major topics came along). Still no clue though :/
lizmat rm -rf ~/.raku/precomp I mean
after a Rakudo update, what is the point of keeping old precomp files anyway ?
nine You don't know that the old Rakudo version is actually gone. C.f. rakubrew 12:41
lizmat I guess we don't have a way to nuke all precomp files of a specific Rakudo version
OOC, would rakubrew actually use ~/.raku/precomp ? 12:42
nine I don't see why it wouldn't. 12:43
Anyway, nuking precomp is just a workaround. There is an underlying issue here that may have other effects and that needs adressing.
lizmat nine: before you put time into that I think there are other issues with precomp that need solving 12:44
perhaps they can be part of the same process :-)
MasterDuke nine: doh. i knew there was a better solution but it just wasn't coming to me 12:53
12:59 jjatria joined 13:00 discord-raku-bot left, discord-raku-bot joined 13:10 linkable6 joined 13:39 frost left
nine There is one definite issue with our build process that leads to "Missing or wrong version of dependency" errors: NQP's source-version does not include MAST::Ops and MAST::Nodes. So if the latter get changed, the nqp version check doesn't trigger a rebuild. 14:05
If one then rebuilds manually (i.e. make clean && make) we do not get a different compiler id, so we end up using outdated precomp files
I don't know if this is the source of the OO::Monitors issue, but it's easy to fix and definitely needs fixing 14:06
lizmat nine: so after a Rakudo bump now, there shouldn't be any issue? 14:19
or at least that's the theory?
nine As I said, this was definitely an issue. I just don't know if it was the OO::Monitors issue. 14:20
lizmat ok, lemme bump and find out :-)
nine I can guarantee that after this rebuild you will not have the issue, as you'll definitely get a new compiler id (since we previously never included MAST:: modules). But I can't promise that the issue will not reappear on a later rebuild. 14:21
lizmat ok, fair enough... good enough reason to bump now anyway :-) 14:24
nine It would be immensely helpful to have steps to reproduce from a clean slate.
lizmat I have just bumped NQP locally , and nuked ~/.raku/precomp so should have a local clean slate now :-) 14:35
meanwhile: kudos to people bumping other libraries, another speed record for test-t just now :-) 14:36
Nicholas "steps to reproduce - give lizmat time and tea" "*reliable* steps to reproduce - ???"
15:03 discord-raku-bot left, discord-raku-bot joined 15:07 discord-raku-bot left, discord-raku-bot joined 15:39 Altai-man left 16:52 [Coke] left 16:58 [Coke] joined 17:14 Guest12 joined 18:07 reportable6 left 18:08 reportable6 joined 18:16 Guest12 left 18:42 MasterDuke left
nine Huh...I got a segfault here in an existskey on a Stash. The associative delegate hash that we're trying to access is NULL. It used to be there, but repossession cleared the Stash object and we never seem to call P6opaque's deserialize on this object afterwards. 18:46
[Coke] anyone have pointers on this windows stacktrace? caught during my "program just stops processing and doesn't throw an error" test. 19:03
looping through 100s of items, it does a much smaller number (sometimes just 1) and stops, no indication of an exception or stack trace. 19:04
(disabling JIT & SPESH have no effect. something changed since about 2 releases ago.) --ll-exception shows nothing 19:05
it does appear to have one of the new dispatch functions in it.
(oh right need to try not using mimalloc) 19:08
That was it, sadly: mimalloc apparently slightly buggy on windows. 19:28
but I can do my builds without and that'll get me by for now 19:29
nine Ooooh.... that makes sense. We just never get to deserialize the repossessed object because an exception throws us out of the MVM_serialization_deserialize we're running 19:44
Well, I can understand MoarVM's reluctance to proceed: "New type Stash for Block is not a mixin type" 19:47
Nuking .precomp changes the symptoms. Segfault is gone, but still: "New type Stash for Perl6::Metamodel::ClassHOW is not a mixin type" 19:51
20:01 MasterDuke joined
MasterDuke [Coke]: do you have a rakudo with the latest moarvm bump to pull in mimalloc 2.0.5? 20:03
btw, anybody have any thoughts on github.com/MoarVM/MoarVM/pull/1645 ?
nine MasterDuke: I'd say, first fix the remaining mimalloc issues. Because right now the "few systems that can't use mimalloc" are not so very uncommon :) 20:05
MasterDuke oh yeah, there's no particular hurry. just keeping it in people's minds 20:07
[Coke]: do you have a link to the stacktrace somewhere?
[Coke] oh, I never resent it. gist.github.com/coke/ae63d0a6efee6...f449632780 20:20
MasterDuke: using rakudo v2022.02-69-g967a130ff2; looks like it's still got moar 2022.02 20:21
MasterDuke hm, i don't think that stacktrace gives any info we can directly use. something got allocated by not-mimalloc and now is being incorrectly freed by mimalloc, but we don't know what 20:23
is github.com/MoarVM/MoarVM/blob/mast...ops.c#L253 ok? 20:38
i don't think we should be MVM_free'ing the return value of getenv(), right? 20:39
Nicholas um, no. not
"The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3)." 20:40
MasterDuke heh 20:42
wow, it's been like that for a while github.com/MoarVM/MoarVM/commit/53...1ae17e9ee2 20:45
[Coke] interesting that it was a windows fix. 20:46
Nicholas it's an easy trap to fall into. The "rules" about getenv/putenv/aaaargh are confusing and crap. And I think for some cases "leak it" is the only option 20:48
"The only winnig move is not to play"
Geth MoarVM: MasterDuke17++ created pull request #1674:
The result of a getenv() call should not be freed