Opened 16 years ago
Last modified 6 years ago
#3085 assigned bug
[Sounds] crashes after playing the event sounds consecutively.
Reported by: | richienyhus | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Preferences/Sounds | Version: | R1/Development |
Keywords: | Cc: | mdisreali@…, degea@… | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
After setting a file as a event sound in the 'sounds' preference app, and playing it a few times, 'sounds' crashes.
File used: http://local.elgsis.lt/files/mipi/mipi-haiku-start2.mp3
Attachments (11)
Change History (31)
by , 16 years ago
Attachment: | soundsprefapp-stacktrace.txt added |
---|
comment:1 by , 16 years ago
Owner: | changed from | to
---|
comment:2 by , 16 years ago
Owner: | changed from | to
---|
comment:3 by , 16 years ago
whoops, I had forgotten that will the auich driver not working in virtualbox at the time(It now works in hrev28555, albeit buggy), I deleted the driver and installed OSS.
This kind of changes things, sorry.
So the problem of 'sounds' crashing still happens, albeit only using the Open Sound System driver.
comment:4 by , 16 years ago
Owner: | changed from | to
---|
This look like it could be a bug in OpenSound, I can't reproduce it here using emuxki. Francois, could you investigate when you have a chance?
comment:6 by , 13 years ago
This issues started occurring on my system sometime after Alpha3 was released. Around the same time, the pref started to fail actually play the sounds. (There may be a seperate ticket for that already.)
I will try to determine on which rev it started. Current install is hrev42930-2hn.
Attaching bt.
by , 13 years ago
Attachment: | r42930-2hn_sounds_preflet_crash_after_clicking_play_several_times.txt added |
---|
comment:7 by , 13 years ago
Forgot to mention that I do not has OSS install. Haiku used the HDA driver. Attaching a zip of the wave file with which I have been testing.
by , 13 years ago
Attachment: | info.wav.zip added |
---|
comment:8 by , 13 years ago
Can't reproduce the crash here, sure it wasn't fixed in hrev42453 ? I do get another one though (pure virtual)...
comment:9 by , 13 years ago
It is very easy to reproduce on my hardware, it only takes 4-10 clicks. My system is known to have sound/audio driver issues, though this is relatively new behaviour on this system.
Attaching a slightly different backtrace and a syslog that hopefully has the KDL session info.
Again, this is on hrev43005-gcc2hybrid nightly installed on an Acer AM5620 desktop.
by , 13 years ago
Attachment: | syslog_r43005-2hn_sounds-pref_crash_on_play.txt added |
---|
by , 13 years ago
Attachment: | r43005-2hn_Sounds_crash_4-clicks.txt added |
---|
comment:10 by , 13 years ago
I have found that simply selecting an Event which has an assigned sound and clicking the "Play" button once, causes Sounds CPU usage to spike and its mem usage to go from 2-3MB to sometimes over 20MB.
Attaching screenshots.
If there is a another way to get similar information, such as from Terminal, that could be more useful, please let me know.
by , 13 years ago
Attachment: | r43005-2hn_sounds_pref_high_cpu_usage_01.png added |
---|
by , 13 years ago
Attachment: | r43005-2hn_sounds_pref_high_cpu_usage_02.png added |
---|
comment:11 by , 13 years ago
Cc: | added |
---|
comment:12 by , 12 years ago
Version: | → R1/Development |
---|
It doesn't crash anymore (at least with BeStartup.wav sound) in hrev45179. Instead, Sounds siliently quits after a few clicks on Play button.
comment:13 by , 11 years ago
Regarding Component: Preferences/Sounds
,
In hrev45824 I witnessed just now a call to system_beep() (specifically, in BeShare) going "click" (brief click then silence, instead of playing the sound).. Went to Preferences/Sounds immediately, but when I selected the corresponding line and clicked "Play" it worked fine. A couple years ago it used to crash as described above. If memory serves, there has been changes in the media-kit but not in "Sounds" since that time, so it seems the MK was the culprit and has much improved since then.
There's a possibility the remaining problem is not in Sounds but rather in the MK implementation of system_beep(). I base that on a MK vulnerability I discovered recently (still have to file a ticket): if playing a sound in a certain way, one may block the media_server, such that all applications accessing it are "frozen". After some digging I found out that my code had to use Preroll()
and call BSoundPlayer::Stop()
before ever delete
ing it (not sure which one of these two fixed it, but the vulnerability is fixed now). So the MK is a bit sensitive to the order in which functions are called to access it. If it can trigger a freeze, it can trigger a "click" or the old crash in older, more vulnerable versions. Maybe system_beep() (as presumably used in Sounds) forgets to call Stop()
before recycling the BSoundPlayer, or something like that.
comment:15 by , 9 years ago
Still reproducible for me. It doesn't seem to happen if you wait until a sound is played back completely (i.e. the stop button get 'un-ghosted'). But it does crash when pressing play e few timmes while it's still playing. Attached is a fresh backtrace with hrev49632.
by , 9 years ago
Attachment: | Sounds-1711-debug-12-09-2015-08-36-24.report added |
---|
crash when clicking 'play' a few times without waiting for the playback to finish
comment:16 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Ok, thanks for the update!
by , 8 years ago
Attachment: | sounds.diff added |
---|
Patch to move out of BGameSound, not properly working though.
comment:17 by , 8 years ago
patch: | 0 → 1 |
---|
comment:18 by , 7 years ago
patch: | 1 → 0 |
---|
comment:20 by , 6 years ago
Owner: | changed from | to
---|
stack trace