Hi!
I have the same problem as explained here: https://www.allegro.cc/forums/thread/613698
I've tried to replicate the problem in the smallest amount of code possible, but haven't succeeded yet. But in the codebase I have now, if I remove al_reserve_samples(), the program quits immediately - if I add it back the program waits for 10 seconds (after the window is gone) before it really quits.
I'm not sure how to debug this. Has anyone looked into this yet?
edit:
I managed to replicate the problem in the smallest amount of code:
Are there corresponding al_destroy_sample()'s at exit? Just guessing here.
To debug you can add in some al_get_time() statements and see how long it is between measurements around each line of code. Something else you can do is run it through the debugger and when you think it is busy doing its thing, then hit CTRL-C and break execution. Then
info threads
and usually check out thread 1, but sometimes all you get is weird system calls. Do a
backtrace
on each thread by switching threads with
thread N
. You don't always get anything useful unless all your libs are debug. Call al_uninstall_audio and the other shutdown functions manually and see which ones take the longest. That may help narrow it down.
When I run this:
It gets stuck at al_uninstall_audio(). I'll try to investigate further.
What is weird is this though: if I comment out the while loop, the program runs and quits immediately.
I traced this all through and the 'slow' part seems to be a call to AudioQueueDispose in aqueue.m.
The second parameter to AQD can be false to dispose of the queue asynchronously and I wonder if that mode might help. Of course, it may well be set to true for a good reason.
Pete
Seems Elias fixed it? https://github.com/liballeg/allegro5/commit/d6d58b28b018e065770bb96b7276fe2cc002cad6
I recompiled allegro with the fix and now my example above quits immediately as it should.
I don't know if that makes me feel really clever or really dumb. Anyway, glad it's fixed.
Maybe the powers that be should consider backporting the fix for 5.0.10?
Maybe the powers that be should consider backporting the fix for 5.0.10?
We need to sit down and make someone do some backporting. And then make a release.