AV in ntdll.dll if FullDebugModeWhenDLLAvailable is enabled
Brought to you by:
pierre_le_riche
Menu
▾
▴
#54 AV in ntdll.dll if FullDebugModeWhenDLLAvailable is enabled
Using either FastMM 4.94 or 4.99 in BCB6, when running one of my projects on Windows 2008 64-bit or Windows 7 64-bit, if FullDebugModeWhenDLLAvailable is enabled, an AV occurs in ntdll.dll that kills the process, but only if one particular modal TForm is shown. Nothing special about that TForm, just a TMS TAdvPanel, a few TMaskEdits, a few TLabels, and a few TPngBitBtns. If I disable FullDebugModeWhenDLLAvailable, or do not show the Tform, then the app does not crash.
Exception EAccessViolation in module ntdll.dll at 00038DA9.
Access violation at address 77378DA9 in module ntdll.dll. Write of
address 00000014.
Hi Remy,
That option is a combination of the FullDebugMode, LoadDebugDLLDynamically and DoNotInstallIfDLLMissing options. It is possible that there is something in the C++ support unit that does not support one or both of the last two options properly. Unfortunately my C++ is very rusty. If you do figure out what is wrong, please let me know so I can update the C++ support file (if it turns out to be a problem there).
Thanks!
Pierre
I have been able to revert our projct to an earlier version that does not crash when using the exact same FastMM source files. I don't think this is a FastMM bug persay, but disabling that option does solve the problem. After much trail and error, I was able to reduce the culprit down to 3 lines of our own code. If the code is present, the crash occurs. If the code is not present, no crash occurs. The problem is, those 3 lines of code are just to add a bool member to a TThread-derived class, initialize that bool in the class constructor, and read the bool value in the Execute() method. Pretty innocent code, huh? It does not make any sense. Could adding a single bool to a class cause size/alignment issues in FastMM?
It is possible that you perhaps have a bad class typecast or buffer overrun issue somewhere related to that class. Without the bool there could be enough empty space at the end of the block used by the class so that the buffer overrun shows no symptoms , but when you add the bool the class fits snugly in the memory block and the buffer overrun causes the next block header to be corrupted.
Something you can try is to add another unused dword to the end of the class to force some extra padding. If it doesn't crash then then my suspicion is probably confirmed.
I hope you find the problem.
Adding extra padding to the class avoids the crash. I had to add 2 dwords before the crash went away, though.
Do you descend off that class? If so, perhaps you are passing an instance of this class to a function or procedure that expects an instance of the descendant, causing the buffer overrun.
No, I do not descend from it. It does, however, descend from another class. Basically TThread -> Base -> Derived, and then I create a couple of instances of Derived. But they are standalone threads doing their own work and not interacting with other classes, they just sit there working and are not touched until app shutdown.