| 4 Apr 2026 |
 EsperLily [she/her] | trying to build from the staging commit immediately before the 21.1.8 merge means recompiling a lot of stuff. from the source tarballs i'm seeing it download right now it looks like it'll be compiling llvm and rust and python3 and a bunch of other stuff. actually doing this is going to take quite a long time | 20:36:32 |
 emily | yeah it takes a few hours | 20:36:49 |
| emily | you can use https://hydra.nixos.org/jobset/nixpkgs/staging to try and find commits that got at least stdenv built | 20:37:13 |
| emily | but no way around doing a lot of builds to bisect a staging regression usually | 20:37:31 |
| emily | especially if there's issues elsewhere in the closure masking whatever introduced the issue, then you need to backport the fix to the earlier commits | 20:37:57 |
| EsperLily [she/her] | does hydra make the results of staging builds available in the binary cache? | 20:41:09 |
| emily | yes, everything Hydra builds goes into the cache | 20:52:30 |
| emily | but it only builds stdenv on staging, everything downstream of that needs to be built yourself | 20:52:43 |
| emily | and it doesn't necessarily build every commit (and even for commits it tries to build, they can get cancelled/time out/fail for reasons not related to whatever you're trying to diagnose; the last case is when you may need to backport later fixes when bisecting) | 20:53:17 |
| emily | it's still a lot less painful than before it did that though | 20:53:33 |
| EsperLily [she/her] | ugh ok wtf. I finally figured out what it's crashing on. The code in question allocates a struct whose last field is defined like char uf_name[4], but it allocates more than the size of this struct based on the actual length of the function name. And then the code does this
// Add a type cast to avoid a warning for an overflow, the uf_name[] array
// can actually extend beyond the struct.
STRCPY((void *)fp->uf_name, name);
(where STRCPY(d, s) is a macro that evalutes to strcpy((char *)(d), (char *)(s)))
so it's casting away the array length, but the actual compiled code invokes __strcpy_chk(fp->uf_name, name, 4), which itself invokes strcpy and then checks how much it copied and whether that was more than 4. The working version just calls strcpy instead of __strcpy_chk.
| 21:06:29 |
| EsperLily [she/her] | did something change with hardening? though it shouldn't be ignoring that cast | 21:07:34 |
| emily | we turned on strictflexarrays1 iirc | 21:09:13 |
| emily | I believe it's UB to do it like that and flexible arrays should be declared as [] or at least [0] or [1] | 21:09:57 |
| emily | see https://nixos.org/manual/nixpkgs/stable/#strictflexarrays1, https://lwn.net/Articles/908817/, https://reviews.llvm.org/D126864, https://developers.redhat.com/articles/2022/09/29/benefits-limitations-flexible-array-members#motivation_for_stricter_standard_conformance | 21:11:03 |
| emily | I'd guess Vim has potentially fixed this upstream in a later version that MacVim is behind, if Vim itself isn't broken? | 21:11:34 |
| emily | heh, that or our Vim package has just had hardeningDisable = [ "fortify" ]; since 2016 🙃 | 21:12:12 |
| emily | actually since earlier. guessing that's very much not necessary these days | 21:12:39 |
| emily | (actually no 2016 is right, but it was earlier in 2016 than I thought) | 21:13:06 |
| emily |
Fortify hardening detects a probable buffer overflow in vim at runtime. This has to be fixed upstream.
reassuring commit messages…
| 21:13:22 |
| EsperLily [she/her] | is this the right flag to disable for this, or is there a more targeted flag that will do it? | 21:22:48 |
| emily | strictflexarrays1 is more targeted, but it's also a one byte fix to https://github.com/vim/vim/blob/master/src/structs.h#L2017-L2019 to avoid the issue entirely | 21:25:00 |
| emily | https://github.com/vim/vim/blob/5943c57173e78ce5b5d82d3e908542b010a31134/src/userfunc.c#L723 even goes bizarrely out of its way to avoid depending on the size | 21:25:22 |
| emily | not sure why they're even doing [4] in the first place | 21:26:02 |
| EsperLily [she/her] | yeah, i just have to wonder why it is defined as [4] and so whether there's any code elsewhere that assumes it's always at least 4 bytes | 21:26:06 |
| EsperLily [she/her] | my best guess is they want to be able to just compare the first 4 bytes to look for special patterns without having to check if it even has 4 bytes of name | 21:26:24 |
| emily | usually it's more about padding out the size of the struct from what I've seen, but rarely with any justification of why they'd want to do that | 21:26:54 |
| EsperLily [she/her] | which i guess they could do by declaring it as [] or [0] and then adding the minimum 4 in alloc_ufunc too | 21:26:57 |
| emily | https://github.com/vim/vim/commit/e01e5215f927f83778ad7494abb0007aa52d08c3 it already got them in hot water with ASAN | 21:27:04 |
| emily | because they were under-allocating | 21:27:23 |
