User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110416 Firefox/6.0a1 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110416 Firefox/6.0a1 Trying to seek while playing a HTML5 video immediately causes a crash, every time. Reproducible: Always Steps to Reproduce: 1. Play HTML5 video 2. Seek 3. Crash Actual Results: Browser crashes in an ALSA library Expected Results: Video would continue playing from seek point Flash not installed. Only happens on 64-bit (no sound under 32-bit). Video will play fine with audio for a long time, it only crashes when seeking. https://crash-stats.mozilla.com/report/index/1fc8e0de-17a6-4fe2-91ad-11ea92110416

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0a1) Gecko/20110419 Firefox/6.0a1 I was unable to reproduce the crash. Can you please try it on a clean profile: http://support.mozilla.com/en-US/kb/Managing%20profiles Thanks!

Thanks for the response! I just tried it with a clean profile, no change: https://crash-stats.mozilla.com/report/index/464aeb57-ce9a-4708-8fe8-709072110420 This crash has been a long standing problem for me, back as far as Firefox 3 but I always thought it was the Flash plugin at fault. I think it is because Firefox uses ALSA to play audio under Linux, and the ALSA API requires you to be particularly careful if the user has plugins loaded - what works with a clean ALSA config may fail if there are plugins in the output chain. (Having said that, every other program on my system that uses ALSA works fine.) If you can install the SWH LADSPA plugins (most distributions put these in a package named something like 'swh-plugins'), try adding the following to your ~/.asoundrc or /etc/asound.conf: pcm.eq { type ladspa slave.pcm "plug:dmix" path "/usr/lib/ladspa" plugins [ { #label mbeq id 1197 input { controls [ -1 -3 -7 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ] } } ] } pcm.!default { type plug slave.pcm "eq" } You may need to tweak it until other programs work correctly (e.g. mplayer) but once they are working try it with Firefox and see if you can reproduce the crash.

Just for the record this is still happening with the latest nightly: Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 http://crash-stats.mozilla.com/report/index/bp-4a1a98ab-59da-48bf-be1b-5dd7b2110524 http://crash-stats.mozilla.com/report/index/bp-ab07b4d6-351c-465a-a732-ac5e72110524 http://crash-stats.mozilla.com/report/index/bp-dfe53bdb-7894-4432-b0dc-7cdd72110524 http://crash-stats.mozilla.com/report/index/bp-24e85f6b-d80b-46b8-b478-a40542110524 http://crash-stats.mozilla.com/report/index/bp-39305fea-56dd-4346-bba5-fe7cf2110524 That was just from one evening, 100% crash rate. Every other audio/video program on the system still works fine...

Adam, are you able to test whether the crash occurs without the LADSPA plugins involved?

Bug 658589 turned out to be the same problem, and the reporter has kindly confirmed that disabling the LADSPA plugins avoids the crash. As I said in bug 658589, someone now needs to install the LADSPA plugins to reproduce this and work out where the bug lies.

I can reproduce a crash with swh-plugins-0.4.15-16.fc12 on Fedora 12. Valgrind reports invalid writes and reads inside the swh-plugin code. It looks like this bug has since been fixed in some version of the code hosted on GitHub: https://github.com/swh/ladspa/commit/3b61bb945c5e09ac4f7e0f4805ff80512af93b8e

Thanks for looking in to this - I just backported that commit to swh-plugins-0.4.15 and it does indeed fix the problem. Hooray! For the benefit of anyone else, the patch against swh-plugins-0.4.15 that fixes this problem can be grabbed from http://www.shikadi.net/files/patches/swh-plugins-0.4.15-mbeq_crash_fix.diff

Verified based on comment 8.