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

[SourceForge.net <no...@so...>]

Bugs item #3102497, was opened at 2010-11-03 15:56
Message generated for change (Comment added) made by trentg
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: Open
Resolution: None
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: Trent Gamblin (trentg)
Date: 2010-11-03 16:36

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

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

Comment By: Trent Gamblin (trentg)
Date: 2010-11-03 16: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-03 16: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