Subtle Corruption and the Debugger [Snippet]
Subtle Corruption and the Debugger [Snippet]
Ever seen an error that literally cannot be debugged? Here's a hint: it's a bug in your debugger.
Join the DZone community and get the full member experience.
Join For FreeBuilt by operators for operators, the Sensu monitoring event pipeline empowers businesses to automate their monitoring workflows and gain deep visibility into their multi-cloud environments. Get started for free today.
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 passed 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.
Download our guide to mitigating alert fatigue, with real-world tips on automating remediation and triage from an IT veteran.
Like This Article? Read More From DZone
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}