|
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 |
09:56 | |
| 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 |
11:38 | |
| 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 |
21:09 | |