First off, I have a library which I built which depends upon Allegro 4.4.1.1. Second, I have a program I wrote which uses my library.

When I link statically to Allegro and to my library, my program stops running after I tell it to quit by using ESC or clicking on the close window button.

When I link dynamically to Allegro and to my library, my program continues to run in the background doing nothing after I tell it to quit.
If I run a debug version that was linked dynamically through the GnuDeBugger, then it exits properly, but does not if I run the debug version outside of gdb.

I used ProcessExplorer to check the status of my program after telling it to exit, and there are two threads left running :

ntdll.dll!RtlUserThreadStart
ntdll.dll!RtlConvertUiListToApiList+0x215

Process Explorer says both threads are in a state of "Wait : User Request".

I know that the atexit routines have been run, because the graphics mode set up by Allegro has been shut down and the onscreen window closes, but the process continues to run as shown by Task Manager and I have to end the process manually.

All libraries and programs were compiled using MinGW 3.4.5 and run on Windows Vista.

Does anyone know what might be causing this behaviour? Or how to solve it? Google has not helped at all.
There is no conditional compilation between dynamic and static versions, so the same code should be running in both instances, so I don't know how to explain it.

Have you tried attaching the debugger to the process when it's in the hung state? That should let you find out what's going on. http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_22.html

Alternatively as a very nasty workaround you can take advantage of the fact that Windows will clear everything up for you when a process exits and just call ExitProcess(0).

Wild guess since you are using Allegro: Have you set up the END_OF_MAIN macro properly?

Alternatively as a very nasty workaround you can take advantage of the fact that Windows will clear everything up for you when a process exits and just call ExitProcess(0).

That's actually not nasty at all, but rather a feature. This way you can have extremely quick shutdowns. Some games are horrid in that they do unnecessary cleanup for 30 seconds before finally dying when there is no point to it (Assassin's Creed, I'm looking at you!).





On topic, an alternative is to try to flag the threads as daemon (background in Win32 terminology) threads by iterating over them, that way the process will die even if they are still alive.

Yes. If I hadn't used END_OF_MAIN, the program wouldn't link at all because of an undefined reference to 'WinMain'.

[quote name='Adam_42']
Have you tried attaching the debugger to the process when it's in the hung state?

That's a good idea, I forgot I could do that.

Well, I attached the backtrace of each running thread. Thread 2 is not so interesting, but thread 1 may shed a little light on what is going on :
[attachment=1897:EagleExitHangThread1.txt]
[attachment=1898:EagleExitHangThread2.txt]

[quote name='Thread 1']
#23 0x0022fd8c in ?? ()
#24 0x644cd575 in update_mouse () at C:/mingw/Allegro4411SVN/src/mouse.c:332
#25 0x76637742 in WaitForSingleObject () from C:\Windows\system32\kernel32.dll
#26 0x000000f0 in ?? ()
#27 0xffffffff in ?? ()
#28 0x00000000 in ?? () from
#29 0x0022fe0c in ?? ()
#30 0x6451c077 in _win_input_unregister_event (event_id=0xf0)
at C:/mingw/Allegro4411SVN/src/win/winput.c:172
#31 0x6451c077 in _win_input_unregister_event (event_id=0x1dc)
at C:/mingw/Allegro4411SVN/src/win/winput.c:172
#32 0x64520396 in mouse_dinput_exit ()
at C:/mingw/Allegro4411SVN/src/win/wmouse.c:543
#33 0x6452078a in mouse_directx_exit ()
at C:/mingw/Allegro4411SVN/src/win/wmouse.c:697
#34 0x644cea28 in remove_mouse () at C:/mingw/Allegro4411SVN/src/mouse.c:1175
#35 0x644816c7 in allegro_exit () at C:/mingw/Allegro4411SVN/src/allegro.c:470
#36 0x644812b1 in allegro_exit_stub ()
at C:/mingw/Allegro4411SVN/src/allegro.c:294
#37 0x70c4110f in DllMainCRTStartup@12 ()
from c:\ctwoplus\progcode\allegro\Eagle\build\TestPrograms\eagle_d.dll
[/quote]

So I thought maybe remove_mouse was causing the problem, so I called that manually, but the program still hangs after the atexit routines are called.

Taking it one step further I called allegro_exit manually instead of letting the atexit routines do it, and now the program no longer hangs upon exiting.

Well, I still don't understand why the program would hang if allegro_exit is called by the atexit routines instead of manually, and only if the program is linked dynamically to my library (It never hung when my library was part of my program's project and I linked to Allegro dynamically).

At least I have a workaround now.