Back in the day I used to consult for Sony Ericsson. We had like 5000 engineers writing C code that ran as a single executable in a single address space(!). Memory corruption was rampant. So rampant in fact that when we finally got an MMU it took months before we could turn it on in release builds, because there were so many memory corruption bugs even in the released product. The software just wouldn’t work unless it could overwrite memory here and there.
The Linux kernel has thousands of engineers writing C code that runs as a single executable in a single address space. Memory corruption is not rampant, since they are careful to write good code, although it can still happen. I am going to guess that Sony Ericsson had a ton of use after free bugs and array out of bounds bugs, as that is the main way that developers can step on each others' code when it shares a process space.
Speaking of which, I once did consulting for a company that insisted that they had hit a bug in ZFS because there were backtraces showing ZFS. Using KASAN, I found that the bug was in fact in another third party kernel module that they used that appeared to be the result of a hobbyist project on github. It had a string function write 1 past the end of a memory allocation, which often would corrupt memory allocations used in ZFS' AVL trees. ZFS' AVL tree code did not like this, so ZFS appeared in backtraces.
That said, the bug described by the unity blog is really an undefined behavior bug rather than a memory corruption bug. Doing an exception in a C++ callback function called by a C function is undefined since C does not support stack unwinding. If the C function does not need any special cleanup when stack unwinding is done, it will probably work fine, but in this particular case, the function needed very special cleanup and invoking undefined behavior bit them.
> The Linux kernel has thousands of engineers writing C code that runs as a single executable in a single address space. Memory corruption is not rampant, since they are careful to write good code, although it can still happen.
Sure, but I’ve rarely seen quality comparable to the Linux kernel in a commercial context.
> I am going to guess that Sony Ericsson had a ton of use after free bugs and array out of bounds bugs, as that is the main way that developers can step on each others' code when it shares a process space.
Mostly yes. But there were some interesting ones too. I debugged one that turned out to be a stack overflow, for example. There was basically this giant function with ridiculously many local variables. When that function called another function the stack pointer was bumped far out of the allotted stack space and the called function overwrote stuff when writing to local variables.
I remember back in the day of the Sony Satio U1, the last Symbian v5 phone, the software was horrendous(screen tearing, random OS freezes) and later, the phone abandoned. I think it was afterwards that Sony and Ericsson split?
