Hiya,
I've seen this issue very rarely on my machine, but is much more reproducable on other machines. Basically on exit, sometimes there is still a program entry on the taskbar which can't be killed apart from by using the task-manager. All logging seems to suggest a clean exit on my programs end..
This is using Allegro 4.2.0 under Windows XP with AllegroGL (SVN) + OpenLayer (SVN)
A search on the forums revealed some problems a few years ago. Has this problem ever being totally fixed, or is it a windows issue?
Cheers!
Rich.
I noticed that problem for the 15-20 minutes I worked on minorhack last weekend. I figured it was some bug in my program, and I ended up not finishing due to lack of time.
Hmmm.. If it is a bug in Allegro it really should be fixed. Especially since it's been reported for a few years. Unfortunately it's very rare on my machine, but some PC's with certain gfx cards (we've had it happen a few times with an old RAGE 128 Pro) do seem to have this problem a lot more. Of course, it may not be the gfx card, it may be the other hardware or software on the PC.
Last I heard, this was a DX problem. Could be wrong though.
No other DX games and such that I have do that.
As far as I know, it was a race condition that was fixed long ago.
This is with vanilla Allegro though, I don't know af AllegroGL has the same possible problem. At any rate, check if you can reproduce the bug with vanilla Allegro.
Hmmm.. If it is a bug in Allegro it really should be fixed.
Richard, you sometimes put me on edge with comments like that. Of course bugs should be fixed.
Evert: Thanks for the info!
BAF, did you use just Allegro, or AllegoGL as well?
Richard, you sometimes put me on edge with comments like that. Of course bugs should be fixed.
Sorry, I thought it might have been forgotten a few years back.
Vanilla Allegro. As I said, I may have had some buggy code myself.
I don't know af AllegroGL has the same possible problem.
Anyone knows what the problem was?
Double check all your memory allocations/deallocations/accesses. Sometimes if you play with memory you aren't supposed to, the program will go fine until sometime after main is finished, where it'll hang. I don't know if there's any Windows program to do it for GCC-made programs, though.
KC: Fortify can track memory overruns.
I'm not sure about a memory overrun, I'm mainly using STL.
Vanilla Allegro. As I said, I may have had some buggy code myself.
Thanks, but I actually meant to ask Richard.
I thought it might have been forgotten a few years back.
Next time, check the changelog before assuming something wasn't looked into:
==============================================================================
============ Changes from 4.2.0 beta 2 to 4.2.0 beta 3 (May 2005) ============
==============================================================================
[...]
Elias Pschernig fixed Allegro's internal multithreading in Windows. This
fixes a deadlock on exit.
[...]
==================================================================
============ Changes from 4.1.11 to 4.1.12 (Nov 2003) ============
==================================================================
[...]
Eric Botcazou changed the default switch mode to SWITCH_BACKGROUND for
the Windows port to cure the problems on exit under WinXP.
Doesn't nescessarily mean it's fixed, but problems of this kind have been looked into.
I apologise if I annoyed you Evert. That wasn't my intention. 
Eric Botcazou changed the default switch mode to SWITCH_BACKGROUND for
the Windows port to cure the problems on exit under WinXP.
Does anyone know if this is changed when Allegro runs it's exits procedure? I do change the switch mode ingame to deal with alt-tabbing. Does anyone think this might occasionally cause a problem?
Thanks.
From the code, it seems not. Can you check if resetting the switch mode helps (call set_display_switch_mode(BACKGROUND) before exiting)?
In that case a patch like below maybe would help (completely untested).
Index: src/win/wsystem.c =================================================================== --- src/win/wsystem.c (revision 7510) +++ src/win/wsystem.c (working copy) @@ -214,6 +214,9 @@ _free_win_digi_driver_list(); _free_win_midi_driver_list(); + /* make sure we are not paused and deadlock */ + _win_reset_switch_mode(); + /* unhook or close window */ exit_directx_window();
Unfortunately it's very very rare on my machine.. Perhaps Baf can help test this with his machine?
It's rare for me too, I'll see if I can get it to reproduce itself then test the patch.
Thanks Baf.