| 4 Apr 2026 |
 Randy Eckenrode | Does it crash with LLVM 22? | 20:17:45 |
 EsperLily [she/her] | i'll try that after i do this build with the old compiler | 20:18:13 |
| EsperLily [she/her] | this works fine, no crash | 20:21:40 |
 emily | then I guess it's not https://github.com/llvm/llvm-project/commit/d2e835bd46384aa1628c9d44e3f93438f0795dfd. well, that or your CFLAGS aren't reaching the right part of the build | 20:22:13 |
| emily | I would perhaps try the staging commit immediately before the 21.1.8 merge and the 21.1.8 merge commit itself | 20:22:51 |
| emily | if those differ then it really does have to be something in https://github.com/llvm/llvm-project/compare/llvmorg-21.1.7...llvmorg-21.1.8 somehow | 20:23:20 |
| emily | if not… well, it's a start on bisecting the cycle | 20:23:29 |
| EsperLily [she/her] | i I run path/to/Vim --version it reports its own CFLAGS as being what I set (plus a few -D flags) | 20:26:23 |
| emily | yeah, but maybe it's something other than that binary? dunno | 20:26:48 |
| emily | non-weird possibilities are pretty much eliminated so whatever it is has to be weird in some way | 20:27:02 |
| EsperLily [she/her] | sadly yes | 20:27:51 |
| EsperLily [she/her] | I used final.llvmPackages_22.stdenv and it still crashes | 20:28:02 |
| emily | I think this will be the best next step, since if it narrows it down to that one merge then there's a very short list of commits that could have caused the regression. | 20:32:20 |
| emily | though it seems basically incomprehensible for it to be anything other than the llvm/lib/CodeGen/SelectOptimize.cpp change if it is | 20:33:12 |
| 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 |
