+972 52-548-6969
Subtle corruption and the debugger
We had a bug. If a certain method was called, we would do something very bad. Here is the fix for this issue:
Basically, we assumed that the passed pointer is a char pointer and not a UTF8 byte pointer. That led to horrible mess down the line, including the fact that the length was pass to the constructor is twice the size of the actual allocated memory.
In rare cases, that would be enough to push us to the next page of memory. If that page of memory wasn’t mapped, we would die with an access violation.
There is just one problem with this scenario. We never called this method in our codebase. This method was implicitly called by the debugger to show nice strings. Which meant that during debugging, sometimes, we would corrupt our own state and end up killing ourselves. For fun, this is the kind of error that literally cannot be debugged.
Comments
While the bug was in the debugging code it could have been easily been in real code. As the purpose of managed code is to avoid such issues do you think that making RavenDB (I assume it's RavenDB codebase) in non-managed language would make much difference in your development process?
Dalibor, I talked about this here:
https://ayende.com/blog/183905-C/product-release-postmortem-things-you-should-never-do-part-ii
And here:
https://www.slideshare.net/OrenEini/rebooting-design-in-ravendb/21
I know that bug :)
Comment preview