If you're handling an out of memory exception, you probably shouldn't allocate memory
With the assistance of Application Verifier, specifically, low resource simulation (also known as fault injection), a tester found a stack overflow condition. As we learned earlier, the important thing to look at when studying a stack overflow is the repeating section.
Contoso!Error::ThrowError+0x39 Contoso!Str::Set+0x35 Contoso!Win32::OpenModuleName+0x54 Contoso!StackTrace::StackEntry::FindModuleInfo+0x1b Contoso!StackTrace::CreateTrace+0x2c Contoso!StackTrace::StackTrace+0x4f Contoso!Error::Error+0x1f
When this stack trace was shown to the development team, they instantly recognized the cause of the problem. And you also have enough information to figure it out, too.
Of the most likely reasons that a method named
Str::Set would throw an error,
which of them match the scenario?
Since we are simulating low resources, the error being thrown is most likely an out of memory error.
Reading the stack dump, the constructor for the
object builds a stack trace object, and the stack trace object
tries to allocate memory for a string in order to do its job.
But that memory allocation fails, because we are out of memory,
Error object is thrown, which builds a stack trace,
which encounters an out of memory error, and so on.
Obviously, the mistake was allocating memory as part of the process of reporting an out of memory condition. You need to be careful to avoid generating the very error that caused your error handler to be called.
- Your exception handler can encounter an exception
- Why does the CreateProcess function modify its input command line?