Closed Bug 622517 Opened 9 years ago Closed 9 years ago
Non-reproducible Fennec crash when playing videos on youtube/html5
Noticed Qt-Fennec crash with the following backtrace when playing WebM videos on youtube/html5. (gdb) #0 NS_StackWalk (aCallback=0x120ff70 <PrintStackFrame>, aSkipFrames=2, aClosure=0x0) at /home/user/mozilla-central/xpcom/base/nsStackWalk.cpp:1488 #1 0x0120fede in ah_crap_handler (signum=11) at /home/user/mozilla-central/toolkit/xre/nsSigHandlers.cpp:125 #2 0x0121277b in nsProfileLock::FatalSignalHandler (signo=11, info=0xad4fbbfc, context=0xad4fbc7c) at nsProfileLock.cpp:226 #3 <signal handler called> #4 0x00e1ff28 in snd_pcm_poll_descriptors_revents (pcm=0xaef81790, pfds=0xad4fbfc0, nfds=1, revents=0xad4fbffa) at pcm.c:1456 #5 0x00e25a8f in snd1_pcm_wait_nocheck (pcm=0xaef81790, timeout=-1) at pcm.c:2375 #6 0x00e25c33 in snd_pcm_wait (pcm=0xaef81790, timeout=-1) at pcm.c:2338 #7 0x00e25d20 in snd1_pcm_write_areas (pcm=0xaef81790, areas=0xad4fc0a0, offset=0, size=512, func=0xe6a180 <ioplug_priv_transfer_areas>) at pcm.c:6655 #8 0x00e6a5da in snd_pcm_ioplug_writei (pcm=0xaef81790, buffer=0xaeeae000, size=512) at pcm_ioplug.c:561 #9 0x00e20644 in _snd_pcm_writei (pcm=0xaef81790, buffer=0xaeeae000, size=2907684800) at pcm_local.h:516 #10 snd_pcm_writei (pcm=0xaef81790, buffer=0xaeeae000, size=2907684800) at pcm.c:1247 #11 0x01a5a05f in sa_stream_write (s=0xaed54550, data=0xaeeae000, nbytes=2934628352) at /home/user/mozilla-central/media/libsydneyaudio/src/sydney_audio_alsa.c:260 #12 0x01a21edf in nsAudioStreamLocal::Write (this=0xaed54400, aBuf=0xa83e4008, aCount=1024, aBlocking=1) at /home/user/mozilla-central/content/media/nsAudioStream.cpp:455 #13 0x02056b87 in mozilla::dom::AudioWriteEvent::Run (this=0xaee04880) at /home/user/mozilla-central/dom/ipc/AudioParent.cpp:59 #14 0x021f4c3f in nsThread::ProcessNextEvent (this=0xaed259a0, mayWait=1, result=0xad4fc28c) at /home/user/mozilla-central/xpcom/threads/nsThread.cpp:626 #15 0x021a2730 in NS_ProcessNextEvent_P (thread=0xaef81790, mayWait=1) at nsThreadUtils.cpp:250 #16 0x021f5621 in nsThread::ThreadFunc (arg=0xaed259a0) at /home/user/mozilla-central/xpcom/threads/nsThread.cpp:278 #17 0x00fc458c in _pt_root (arg=0xaef8dbe0) at /home/user/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:187 #18 0x005fe96e in start_thread (arg=0xad4fcb70) at pthread_create.c:300 #19 0x008a2a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
This might be a dupe of bug 622211, are you able to test the patch attached to that bug and verify? The other thing I'm wondering is why we're remoting audio in this case in the first place. As far as I understand, audio remoting is only required for Android. Right now we've got it enabled for all configurations using OOP tabs/content, but I think we should be more selective--the platforms that don't absolutely require remoted audio would benefit from the lower overhead of not being forced to remote audio. ccing Doug for his thoughts.
yes, this should be #ifdef ANDROID only. I wanted it to be maemo and android for a few releases, but there is no sense in causing maemo any pain.
Only hand out remote nsAudioStreams on Android.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #501900 - Flags: review?(doug.turner)
Comment on attachment 501900 [details] [diff] [review] patch v0 Hmm. how about add a #define at the above: #ifdef ANDROID #define MOZ_REMOTE_AUDIO #endif Then replace all of the MOZ_IPCs in that file?
Attachment #501900 - Flags: review?(doug.turner) → review+
that way is fine, but I'd really like to see comment 4.
Attachment #502394 - Flags: approval2.0? → approval2.0+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
It'd be cleaner if you replace all the MOZ_IPCs with REMOTE_AUDIO, as was suggested in comment 4. No need to compile stuff just to have it stripped out 'coz it's unused.
You need to log in before you can comment on or make changes to this bug.