Comment by LeifCarrotson
3 months ago
Broken software causes null pointer references and similar logic errors. It would be extremely unusual to have an inadvertent
ptr ^= (1 << rand_between(0,64));
that got inserted in the code by accident. That's just not the way that we write software.
Except no one is claiming the bit flip is the pointer vs the data being pointed to or a non pointer value. Given how we write software there’s a lot more bits not in pointer values that still end up “contributing “ to a pointer value. Eg some offset field that’s added to a pointer has a bit flip, the resulting pointer also has a bit flip. But the offset field could have accidentally had a mask applied or a bit set accidentally due to the closeness of & and && or | and ||.
I think that if you hit the crash in the same line of code many times, you can safely assume it's your own bug and not a memory issue.
If it's only hit once by a random person, memory starts being more likely.
(Unless that LOC is scanning memory or smth)
Deduplicating and identifying the source of a crash point is surprisingly hard, to the point that “it’s the only crash of its kind” could be a bug in your logic for linking issues.
Also, in an unsafe language all bets are off. A memory clobber, UAF or race condition can generate quite strange and ephemeral crashes. Even if the majority of time it generates the “same” failure mode, it can still sporadically generate a rare execution trace. It’s best to stop thinking of these as deterministic processes and more as a distribution of possible outcomes.
1 reply →