[AD] [ alleg-Bugs-3102497 ] al_destroy_sample crashes if sample still playing

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #3102497, was opened at 2010-11-04 08:56
Message generated for change (Settings changed) made by tjaden
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3102497&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Addons
Group: 4.9
>Status: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Trent Gamblin (trentg)
Assigned to: Nobody/Anonymous (nobody)
Summary: al_destroy_sample crashes if sample still playing

Initial Comment:
I didn't notice this problem until I started testing my game on Windows, specifically when compiling with MSVC. I'm reasonably confident that this is the cause of the crashes I was getting. The majority of them I fixed with a single al_stop_sample, and played for quite a while before getting the same (garbled) stack trace. I looked at the code (for the mini game) and it had the same pattern as the code I fixed before. So I'm reasonably sure that stopping the sample before destroying it is necessary.

----------------------------------------------------------------------

Comment By: Peter Wang (tjaden)
Date: 2010-11-04 10:37

Message:
I will probably apply some form of the patch, as it's pretty much
impossible for the user to get this right in general (apart from calling
al_stop_samples to stop everything first).

----------------------------------------------------------------------

Comment By: Trent Gamblin (trentg)
Date: 2010-11-04 09:36

Message:
Ok, so long as it's documented, it's fine.

----------------------------------------------------------------------

Comment By: Trent Gamblin (trentg)
Date: 2010-11-04 09:35

Message:
As a side note, maybe the documentation for al_stop_sample could be updated
to say something like "Pass the sample id of the last played sample, not
any previous sample ids".

----------------------------------------------------------------------

Comment By: Peter Wang (tjaden)
Date: 2010-11-04 09:33

Message:
Yes, this is documented. This is really a bug in the user program, like
destroying a parent bitmap while a sub-bitmap still points to it, although
the user is less likely to make that mistake.

I have a slightly ugly patch that would stop sample instances
automatically, but there's a *very* rare corner case where the automatic
stopping behaviour might be unwanted. When you have two sample pointing to
the same underlying buffer; start two sample instances; destroy one of the
samples. Because the underlying buffer is the same, both sample instances
would be stopped...  like I said, very rare case...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3102497&group_id=5665