885002 - Segfault in FileBlockCache::Run when playing a movie

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Gustavo Luiz Duarte]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36

Steps to reproduce:

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

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 :-)

Comment 1

[Gustavo Luiz Duarte]

Follows the stack trace:

(gdb) bt full
#0  mozilla::FileBlockCache::Run (this=0x3fff998ce530)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/content/media/FileBlockCache.cpp:216
        lock = {mMonitor = 0x3fff998ce540}
        change = {mRawPtr = 0x0}
        mon = {mMonitor = 0x3fff998ce568}
#1  0x00000080febbec6c in nsThread::ProcessNextEvent (this=0x3fff95b94520, 
    mayWait=<optimized out>, result=0x3fff907fe62f)
    at /usr/src/debug/xulrunner-21.0/mozilla-release/xpcom/threads/nsThread.cpp:627
        event = {<nsCOMPtr_base> = {
            mRawPtr = 0x3fff998ce530}, <No data fields>}
        notifyMainThreadObserver = <optimized out>
        obs = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
        canary = {static sOutputFD = 0}
        rv = NS_OK
#2  0x00000080feb7aca0 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
        val = true
#3  0x00000080febbf7a4 in nsThread::ThreadFunc (arg=0x3fff95b94520)
265
        self = 0x3fff95b94520
        event = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
#4  0x00000080fbb8d54c in _pt_root (arg=0x3fff97dd72b0)
    at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:191
        thred = 0x3fff97dd72b0
        tid = <optimized out>
#5  0x00000080f961c29c in start_thread (arg=0x3fff907ff1c0)
    at pthread_create.c:310
        pd = 0x3fff907ff1c0
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-394642300145193832, 
                553939931384, -394683355316188840, 70366873514624, 
                70366873514624, 70366873516240, 131072, 70366873387008, 0, 3, 
                70366997082800, 553979227640, 70368744163352, 553939916896, 
                553939916912, 65536, 70368744163360, 70368744163360, 4001536, 
                553939894768, 70366873511824, -3187652540, 
                0 <repeats 42 times>}, mask_was_saved = 0}}, priv = {pad = {
              0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
              canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
#6  0x00000080f950d110 in .__clone ()
    at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:111
No locals.
(gdb)

Comment 2

[Gustavo Luiz Duarte]

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=974718

Comment 3

[Steve Singer (:stevensn)]

I have seen this as well on ppc64 but not ppc32

Comment 4

[Steve Singer (:stevensn)]

Line 212 in FileBlockCache.cpp
int32_t blockIndex = mChangeIndexList.PopFront();

is getting back 0 when it should get back 1 on the second block.

The ObjectAt() method in FileBlockCache.h is implemented as follows

 int32_t ObjectAt(int32_t aIndex) {
      void* v = nsDeque::ObjectAt(aIndex);
      // Ugly hack to work around "casting 64bit void* to 32bit int loses precision"
      // error on 64bit Linux.
      return *(reinterpret_cast<int32_t*>(&v));
    }

In the debugger (on ppc64) 

(gdb) p v
$20 = (void *) 0x1
(gdb) p (int32_t)v
$21 = 1
(gdb) p (int32_t*)(&v)
$22 = (int32_t *) 0x3fff9775e310
(gdb) p *(int32_t*)(&v)
$23 = 0

Comment 5

[Steve Singer (:stevensn)]

Attachment: 885002.patch

This patch gets should get the compiler to pick the right 32 bits for the conversion

Comment 6

[Matthew Gregan [:kinetik]]

Attachment: fix?

That code violates strict aliasing rules.  Does this help?

Comment 7

[Matthew Gregan [:kinetik]]

Comment on attachment 826560 [details] [diff] [review]
fix?

Patch race.

Comment 8

[Steve Singer (:stevensn)]

https://tbpl.mozilla.org/?tree=Try&rev=7538d134a4e7

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 826559 [details] [diff] [review]
885002.patch

Review of attachment 826559 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine.

We should just use std::deque instead of nsDeque (I'm not asking you to make this change, just moaning in general).

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b7b720064c9d

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b7b720064c9d

Comment 12

[u279076]

Gustavo, can you please verify this is fixed in the latest Aurora build?

Comment 13

[u279076]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)
> Gustavo, can you please verify this is fixed in the latest Aurora build?

Canceling this long overdue request.