From: SourceForge.net <no...@so...> - 2010-11-03 23:37:27
|
Bugs item #3102497, was opened at 2010-11-04 08:56 Message generated for change (Comment added) 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: 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: 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 |