I've created a function which allocates an array, which is too big, on the stack (C ). The run results with this error:
Unhandled exception at 0x000000013F4DEBF7 in xxx.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000000000043000).
I've never seen the "parameters" section assigned to a particular instance of a stack overflow error, and my search on the internet yielded no results. Does anyone know what these parameters mean? I've observed that for multiple runs of the same code, the first parameter stays constant and the second parameter changes, but stays in the 6-5 digit range. I'm very curious as to what they mean.
In case it matters, here's a MRE:
constexpr uint8_t LOG_2_OF_BUCKET_COUNT = 20;
int main(){
uint32_t histogram[1 << LOG_2_OF_BUCKET_COUNT];
return 0;
}
CodePudding user response:
The "parameters" are described in the documentation for the EXCEPTION_RECORD
struction
Unfortunately for your purposes, the official documentation only describes parameters for EXCEPTION_ACCESS_VIOLATION
and EXCEPTION_IN_PAGE_ERROR
and says for all other exception types the parameters array has undefined contents.
With that caveat noted, there is consistency between the parameters for the two exception types where they are documented, and stack overflow is internally detected via an access violation, so it makes sense to decode as described for EXCEPTION_ACCESS_VIOLATION
. Specifically:
The first element of the array contains a read-write flag that indicates the type of operation that caused the access violation.
- If this value is zero, the thread attempted to read the inaccessible data.
- If this value is 1, the thread attempted to write to an inaccessible address.
- If this value is 8, the thread causes a user-mode data execution prevention (DEP) violation.
The second array element specifies the virtual address of the inaccessible data.
Comparing to your captured exception information, the first element being a flag for (illegal read / illegal write / NX violation) is entirely believable. The second element does not look much like a virtual address, however. Perhaps for EXCEPTION_STACK_OVERFLOW
it gets reported relative to the thread stack base address.