Strange Heap Corruption

[ModShop]

Or at least I think the problem involves some kind of memory error. I'm making a program in SFML and I'm currently working on the menus using a GUI class that I made just for SFML. Internally, the GUI class uses std::shared_ptr to manage all of its internal pointers. The program consistently crashes after main() exits and all global destructors have been called, and gdb says a break point was triggered in ntdll!WaitForAlpCompletion, which leads me to believe that the problem is memory corruption. Whenever I remove the GUI instantiation from the menu function, it exits and closes with no errors. This seems to indicate GUI as the cause of the crash, except that sub-menus which create and destroy their own instances of GUI can be called and exited without any crashes or break points.

Some psuedocode:

SubMenu
{
    Create GUI
        Do Menu
    Destroy GUI
}

Menu
{
    Create GUI
        Do Menu?SubMenu
    Destroy GUI
}

main
{
    Init Stuff
    Menu
    UnInit Stuff
    Destroy GUI
    return 0
}

//after return
Global Dtors
Breakpoint triggered???

I'm at a loss as to what this could be. I plan on using some memory debugger like valgrind sometime today, but I was wondering if anyone else had any ideas on what this could be.

[Computergeek01]

I would start by commenting out the destructors, to me it sounds like one of them is being called twice for some reason.

[zb0S216C]

A heap corruption can be caused with this code:

int main()
{
    int *A(new(std::nothrow) int(10));
    int *B(A);

    delete B;
    delete A;
}

Does any of your code contain this similar situation?

_Wazzak

[ModShop]

@Computergeek01: I just tried that, no luck. I also added debug output to each destructor, but each was only called once.

@Framework: That was what I was thinking, which prompted me to convert to shared_ptr. Now according to CodeBlock's "find" tool, I don't have a singe use of the delete keyword. I wonder if its possible that I somehow managed to mess up shared_ptr... EDIT: Storing shared_ptr's in a std::map wouldn't cause problems, would it?

[ModShop]

I made my GUI class a separate program, devoid of all other classes and whatnot of my main program, and the error persists. The problem is defiantly with GUI.

GDB output:

Program received signal SIGTRAP, Trace/breakpoint trap.
In ntdll!TpWaitForAlpcCompletion () (C:\Windows\system32\ntdll.dll)
#0  0x77bf0475 in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll
#1  0x0028afe0 in ?? ()
#2  0x77bb29c0 in ntdll!RtlCopyExtendedContext () from C:\Windows\system32\ntdll.dll
#3  0x052ffae8 in ?? ()
#4  0x052ffae8 in ?? ()
#5  0x77b4b8ba in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#6  0x6d143c86 in ?? ()
#7  0x000012f4 in ?? ()
#8  0x0028b028 in ?? ()
#9  0x77bf14cf in ntdll!TpQueryPoolStackInformation () from C:\Windows\system32\ntdll.dll
#10 0x00870000 in ?? ()
#11 0x052ffae8 in ?? ()
#12 0x77b4b8ba in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#13 0x7e0fe4d7 in ?? ()
#14 0x00870000 in ?? ()
#15 0x00870000 in ?? ()
#16 0x00000000 in ?? ()

Looks like a memory error to me, but I'm not sure what could be causing it...

EDIT:
I messed with my program a bit and managed to get a different crash, a segfault actually. But it is inside some system dll that is called by sfml_audio.dll.

Program received signal SIGSEGV, Segmentation fault.
In ole32!CoFileTimeToDosDateTime () (C:\Windows\syswow64\ole32.dll)
#0  0x758ca4b9 in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#1  0x758ca423 in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#2  0x758ca548 in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#3  0x758cb2ca in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#4  0x758c9f6a in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#5  0x758c9e25 in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#6  0x758c9d86 in ole32!CoFileTimeToDosDateTime () from C:\Windows\syswow64\ole32.dll
#7  0x758c9d3f in ole32!CoFileTimeNow () from C:\Windows\syswow64\ole32.dll
#8  0x671be880 in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#9  0x671be668 in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#10 0x671be43a in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#11 0x671c3ea0 in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#12 0x671be43a in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#13 0x671c35e9 in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#14 0x671c3a7c in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#15 0x671c3646 in DirectSoundCaptureCreate () from C:\Windows\SysWOW64\dsound.dll
#16 0x66e55006 in alcCloseDevice () from C:\Windows\SysWOW64\openal32.dll
#17 0x05fe0048 in ?? ()
#18 0x00000001 in ?? ()
#19 0x0028fdfc in ?? ()
#20 0x0087155c in ?? ()
#21 0x68201277 in __tcf_0 () from C:\Windows\SysWOW64\sfml-audio-2.dll
#22 0x68201026 in __dll_exit () at ../mingw/dllcrt1.c:145
#23 0x00000003 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

For some reason, however, the program only crashes now when I run it inside the debugger, the error doesn't cause a crash when the App is run by itself.

[rapidcoder]

Are you sure you are not overruning memory of some of your objects? E.g. off-by-one error when traversing an array, etc? Delete is not the only way to corrupt heap in C++. Try to run it under valgrind. It may save you weeks of debugging.

[ModShop]

Finally figured it out!!!!! It turns out that std::map calls the destructors of its objects every time it is re-sized, causing the shared_ptr's within to delete their data several times. A few "quick" design changes and fixed :) Thanks guys!

[ne555]

That doesn't make sense.
std::map doesn't need reallocation
shared_ptr's destructor will only delete the data if it is the only one that is pointing there.

[ModShop]

That's what I thought too, it was probably something of my own doing, but my debug output showed very clearly that destructors were being called multiple times for objects, without constructors being called. I imagine that this threw off the reference count of shared_ptr, making it delete its data.