3 ms·

The computer seems to have identified source code to blame though? Unless of course it hallucinated which there’s always a non zero chance of

fwlr 2mo ago
I mean, we are deep into reading tea leaves at this point, but what it seems to have identified is the source file that changed such that this issue can now occur. My gut instinct is that the changed code is still valid and correct, but it exercises the hardware in a different or a more intense way.
MBCook 2mo ago
It’s the kernel. Nothing a user space library can do should ever be able to call this. Just happens to be that the musl code is able to hit this and other code isn’t for some reason.
- entrope 2mo ago
  > It’s the kernel. Nothing a user space library can do should ever be able to call this. I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?
  - cyberax 2mo ago
    It got traced to a race condition in munmap() in the kernel. The inefficient musl allocator simply triggers it more easily.
    - entrope 2mo ago
      It got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.
      - cyberax 2mo ago
        Andy Lutomirski seems to think that it is a bug: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-... I looked at the explanation, and it seems to be at very least plausible. The kernel version bisection also lines up. We'll see if the proposed patch fixes this.
- inigyou 2mo ago
  User code calls kernel code all the time - just not by its address.

fwlr 2mo ago

I mean, we are deep into reading tea leaves at this point, but what it seems to have identified is the source file that changed such that this issue can now occur. My gut instinct is that the changed code is still valid and correct, but it exercises the hardware in a different or a more intense way.

MBCook 2mo ago

It’s the kernel. Nothing a user space library can do should ever be able to call this. Just happens to be that the musl code is able to hit this and other code isn’t for some reason.

entrope 2mo ago
> It’s the kernel. Nothing a user space library can do should ever be able to call this. I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?
- cyberax 2mo ago
  It got traced to a race condition in munmap() in the kernel. The inefficient musl allocator simply triggers it more easily.
  - entrope 2mo ago
    It got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.
    - cyberax 2mo ago
      Andy Lutomirski seems to think that it is a bug: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-... I looked at the explanation, and it seems to be at very least plausible. The kernel version bisection also lines up. We'll see if the proposed patch fixes this.
inigyou 2mo ago
User code calls kernel code all the time - just not by its address.