I've been receiving an intermittent crash in d3d_shutdown when my program exits. Why would it crash on the line _al_d3d->Release() unless _al_d3d was an invalid pointer? My window sets up fine and I don't believe I am double freeing anything.

I'm using MinGW 4.5.0 on Vista with latest Allegro from Git.

Any ideas why this is happening?

I think it has something to do with my reworked timer class but I don't know what. I've got a thread that runs TimerProcess and communicates with an Allegro5Timer through means of an ALLEGRO_EVENT_QUEUE. States between the TimerProcess and the Allegro5Timer are synchronized using the allegro event queues. When the timer sends a message to the timer process, it waits for a matching return message so that the states are synchronized. I don't destroy anything twice, I'm sure, and I destroy every ALLEGRO_THREAD, ALLEGRO_TIMER and ALLEGRO_EVENT_QUEUE that I create.

Here's the code for Allegro5Timer.cpp if it helps.

And here's my main function :

int ThreadingTestMain(int argc , char** argv) {
   
   (void)argc;
   (void)argv;

   Allegro5System sys;
   sys.InitializeSystem();

   return 0;
}

The sys constructor just initializes everything to zero, and here's the code for InitializeSystem :

So, my system creates a system timer, calls Create on it to create it, and then it gets destroyed by the destructor. Just simple code to test things right now.

I don't see what I'm doing to cause a crash in d3d_shutdown. Ideas?

EagleThread is just a small wrapper around an ALLEGRO_THREAD. Allegro5Timer::Create new's an Allegro5Thread (the wrapper class) and calls Create on it to create a new thread. If it is successful, the thread is started and synchronized by message. The ALLEGRO_THREAD is destroyed in the destructor of Allegro5Thread, which is called by Allegro5Timer::Destroy after the thread has been joined.

No, all I use are ALLEGRO_THREADS at this point. If I write a driver for a different backend I might have to use pthreads, I don't know.

I don't understand, because all I do is initialize allegro and all the addons, then create a timer which uses an ALLEGRO_THREAD to monitor the ALLEGRO_EVENT_QUEUE that has subscribed to my ALLEGRO_TIMER. I initialize some resources, and then I shut down.

Where do you think the crash is coming from? A double free? On my part? On Allegro's part?

I'm currently linking dynamically to allegro, and to my library and to my backend. I built the static debug versions of them and tried it, and results were exactly the same.

Back in 5.0.0RC1 there was a crash in d3d_shutdown that was similar but I don't know if it was ever solved :
https://www.allegro.cc/forums/thread/605549/892332#target

I varied my code according to some ideas in that thread, and it still crashes in the same place.

Funny thing is, it doesn't crash during the manual call to al_uninstall_system but it does crash in al_uninstall_system when the exit routines run.

Program received signal SIGSEGV, Segmentation fault.
0x693df8b7 in d3d_shutdown () at C:\mingw\LIBS\A5GIT\allegro\src\win\d3d_disp.cpp:2604
2604       _al_d3d->Release();
(gdb) bt
#0  0x693df8b7 in d3d_shutdown () at C:\mingw\LIBS\A5GIT\allegro\src\win\d3d_disp.cpp:2604
#1  0x693cfa88 in win_shutdown () at C:\mingw\LIBS\A5GIT\allegro\src\win\wsystem.c:197
#2  0x6936fcd1 in shutdown_system_driver () at C:\mingw\LIBS\A5GIT\allegro\src\system.c:77
#3  0x69363fe1 in _al_run_exit_funcs () at C:\mingw\LIBS\A5GIT\allegro\src\exitfunc.c:92
#4  0x69370015 in al_uninstall_system () at C:\mingw\LIBS\A5GIT\allegro\src\system.c:302
#5  0x6ab41086 in __dll_exit () from c:\ctwoplus\progcode\eagle5gui\cbbuild\bin\eagle_a5d.dll
#6  0x6ab4110a in DllMainCRTStartup@12 () from c:\ctwoplus\progcode\eagle5gui\cbbuild\bin\eagle_a5d.dll
#7  0x77aaded4 in ntdll!RtlDefaultNpAcl () from C:\Windows\system32\ntdll.dll
#8  0x77a9a959 in ntdll!RtlExtendMemoryBlockLookaside () from C:\Windows\system32\ntdll.dll
#9  0x77a9a8db in ntdll!RtlExtendMemoryBlockLookaside () from C:\Windows\system32\ntdll.dll
#10 0x76933d77 in KERNEL32!ExitThread () from C:\Windows\system32\kernel32.dll
#11 0x00000000 in ?? ()
(gdb)

Edit

This does not crash :

   Allegro5System* sys = new Allegro5System();
   delete sys;

This crashes :

   Allegro5System* sys = new Allegro5System();
   sys->InitializeSystem();
   delete sys;

This does not crash :

   Allegro5System* sys = new Allegro5System();
   sys->InitializeSystem();
   delete sys;
   al_uninstall_system();

And now, this does not crash anymore when it did before :

   Allegro5System* sys = new Allegro5System();
   sys->InitializeSystem();
   delete sys;
   al_uninstall_system();
   Sleep(3000);

Anyone have any ideas how I should go about debugging this? I've already been down into every single code branch that InitializeSystem goes into, and I haven't seen anything wrong.

The only D3D or DX I'm using is whatever Allegro is using behind the scenes.

Why is D3D running when I haven't even opened a display yet?

I just tried ripping the guts out of EagleSystem::InitializeSystem and putting them in main and I can't reproduce the crash, even while executing pretty much the same code.

I wasn't even creating a display though. All I was calling was al_init(). Then create some allegro stuff and then destroy it all and shutdown allegro.

I could try changing the order I destroy things in and see if that helps. I thought all event sources unsubscribed themselves upon destruction, but maybe they don't. Well no al_destroy_event_queue says it auto de-registers. So I don't know why that would be it. Maybe my thread is still running but I join it in the destructor so it shouldn't be.

I really don't have any other idea what it might be.

You still didn't tell us if the problem persists when you use opengl.
Anyway, you might actually have heap corruption, as Thomas pointed out. Try using crt heap checking functions.

I think you can still change the "new" display driver.

I do find it odd that its trying to call any d3d "disp" code at all without any displays being created.

Sorry, but MinGW 4.5.0 doesn't come with crtdbg.h or any other header with _CrtCheckMemory in it. Otherwise I would do it. They are specific to MSVC++, which I have installed, but I have never used it, and it would take me a long time to get my libraries set up with a solution. Also, MSVC++ wants me to register, and when I go to obtain a registration code, I am greeted with a Microsoft login. Yet another account to create.

I don't see why it's impossible to use crt function in gcc, since they are all part of msvcrt.dll which every windows user should have (with proper linking and headers). Anyway, I never used mingw, but there should be something specific to gcc/mingw or whatever, which can check if the heap is corrupted.
Maybe this question on stackoverflow can help you:
http://stackoverflow.com/questions/1761125/gcc-memory-leak-detection-equivalent-to-microsoft-crtdbg-h/1761159
EDIT: However, memory leaks which most of them seem to be talking about is not the same as heap corruption.
I still think that on windows you should somehow use windows crt functions and not linux-specific stuff which might actually never work on windows.
Ypu can also try to detect the offending code by shortening your program. Create the shortest possible example of your program which causes your problem. Like, try to replace your own timer with the standard allegro one, etc.

Nope. MingW's entire purpose is to be a GCC that uses msvcrt.dll. Otherwise you get stuck with Cygwin and all of its nonsense.

It probably is. You'd probably need to find the MSVC declaration and copy it into a gcc compatible format.

If you can post a complete program that shows the problem I can try compiling it in Linux and run it through valgrind. If there is something in your code it may show up there.

Cross platform develpmnt is a great way to find bugs.