Bug 974718 - Segfault in FileBlockCache::Run when playing a movie
Segfault in FileBlockCache::Run when playing a movie
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
19
ppc64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-14 21:04 EDT by Benjamin Herrenschmidt
Modified: 2013-11-08 11:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-08 11:14:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Benjamin Herrenschmidt 2013-06-14 21:04:32 EDT
Description of problem:

When clicking the play button of the "intro" movie, or later on,
an embedded youtube widget, firefox segfaults on a NULL defeference,
more data below.

Version-Release number of selected component (if applicable):

Version     : 21.0
Release     : 3.fc19
Architecture: ppc64
Install Date: Sat 15 Jun 2013 09:21:36 EST
Group       : Applications/Internet
Size        : 33386446
License     : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/SHA1, Tue 04 Jun 2013 03:15:11 EST, Key ID 0562eb6fba094068
Source RPM  : firefox-21.0-3.fc19.src.rpm
Build Date  : Tue 04 Jun 2013 02:18:13 EST
Build Host  : ppc-builder1.qa.fedoraproject.org

How reproducible:

100%

Steps to Reproduce:
1. Get a page with a movie (example: http://www.networkworld.com/community/node/83211)

2. Click play
3. Wait for the segfault

Actual results:

segfault

Expected results:

play the movie :-)

Additional info:

Attaching gdb, I observe that it crashes on a NULL dereference here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fff9bf7f1c0 (LWP 8376)]
mozilla::FileBlockCache::Run (this=0x3fff90e11390)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/content/media/FileBlockCache.cpp:216
216	      if (change->IsWrite()) {
(gdb) p change
$1 = {mRawPtr = 0x0}
(gdb) backtrace 
#0  mozilla::FileBlockCache::Run (this=0x3fff90e11390)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/content/media/FileBlockCache.cpp:216
#1  0x00000080e6dcec7c in nsThread::ProcessNextEvent (this=0x3fff91c709c0, 
    mayWait=<optimized out>, result=0x3fff9bf7e62f)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/xpcom/threads/nsThread.cpp:627
#2  0x00000080e6d8acb0 in NS_ProcessNextEvent_P (thread=<optimized out>, 
    mayWait=<optimized out>)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/objdir/xpcom/build/nsThreadUtils.cpp:238
#3  0x00000080e6dcf7b4 in nsThread::ThreadFunc (arg=0x3fff91c709c0)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/xpcom/threads/nsThread.cpp:265
#4  0x00000080e361d54c in _pt_root (arg=0x3fff94411ec0)
    at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:191
#5  0x00000080e186c29c in start_thread (arg=0x3fff9bf7f1c0)
    at pthread_create.c:310
#6  0x00000080e175d110 in .__clone ()
    at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:111

The surrounding code block looks like this:

206	    // Hold a reference to the change, in case another change
207	    // overwrites the mBlockChanges entry for this block while we drop
208	    // mDataMonitor to take mFileMonitor.
209	    int32_t blockIndex = mChangeIndexList.PopFront();
210	    nsRefPtr<BlockChange> change = mBlockChanges[blockIndex];
211	    NS_ABORT_IF_FALSE(change,
212	      "Change index list should only contain entries for blocks with changes");
213	    {
214	      MonitorAutoUnlock unlock(mDataMonitor);
(gdb) 
215	      MonitorAutoLock lock(mFileMonitor);
216	      if (change->IsWrite()) {
217	        WriteBlockToFile(blockIndex, change->mData.get());
218	      } else if (change->IsMove()) {
219	        MoveBlockInFile(change->mSourceBlockIndex, blockIndex);
220	      }
221	    }

I tried to look at blockIndex value but it's been optimized out
at the point of the crash.
Comment 1 Benjamin Herrenschmidt 2013-06-14 21:05:29 EDT
A bit more info in case that's of any relevance: This is a gnome3 session over VNC on ppc64 (thus successfully using the new ppc64 port of llvmpipe which is recent fc19's)
Comment 2 Benjamin Herrenschmidt 2013-06-17 17:33:13 EDT
More data: xulrunner was 21.0-6.fc19, updated to -8.fc19 and the problem
is still there
Comment 3 Gustavo Luiz Duarte 2013-06-19 16:36:03 EDT
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=885002
Comment 4 Martin Stransky 2013-07-24 10:35:12 EDT
Thanks for the report, let's trace it upstream.
Comment 5 Gustavo Luiz Duarte 2013-11-06 08:14:10 EST
Looks like upstream has a fix at:
https://hg.mozilla.org/mozilla-central/rev/b7b720064c9d

Can we add it to Fedora?
Comment 6 Martin Stransky 2013-11-06 08:17:40 EST
Okay.
Comment 7 Martin Stransky 2013-11-08 11:14:33 EST
Added to xulrunner-25.0-3.fc21

Note You need to log in before you can comment on or make changes to this bug.