Closed
Bug 466388
Opened 16 years ago
Closed 15 years ago
Firefox w/ jemalloc crashes when full-screening YouTube video
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 469439
People
(Reporter: dholbert, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: [sg:dupe 469439])
STEPS TO REPRODUCE: 1. Load any YouTube video (e.g. http://www.youtube.com/watch?v=euZ0j7vtKEQ ) 2. Click the YouTube "fullscreen" button (2nd button from the right on the YouTube video controls) EXPECTED RESULTS: Fullscreen video ACTUAL RESULTS: Crash * OS: Ubuntu 8.10, up-to-date * Browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre ID:20081121020528 * Flash: 10.0 r12 (package version "10.0.12.36ubuntu1") Crash reports: http://crash-stats.mozilla.com/report/index/3eb8b3b4-9c08-4cb3-9323-c4d692081123 http://crash-stats.mozilla.com/report/index/2a97c621-689b-40d9-ac11-d87fa2081123 http://crash-stats.mozilla.com/report/index/84137661-e768-4393-b16e-681e12081123 http://crash-stats.mozilla.com/report/index/d0293f32-f21d-4511-9c34-79b4c2081123 I'm initially filing this as security-sensitive, because the crash reports are a little cryptic and scary-looking. (random locations in libc)
Reporter | ||
Comment 1•16 years ago
|
||
I *don't* crash with Ubuntu's Firefox 3.0.4 build (using the same Flash version). That Firefox build ID is: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4 --> Adding regression & regressionwindow-wanted keywords
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 2•16 years ago
|
||
Here's the abort & backtrace that I get, if I catch the crash in GDB with a debug build: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb3bccb90 (LWP 22763)] 0xb7f1e430 in __kernel_vsyscall () (gdb) bt #0 0xb7f1e430 in __kernel_vsyscall () #1 0xb6fcf880 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb6fd1248 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x080594a7 in arena_malloc (arena=0xb6c66040, size=24, zero=false) at /mozilla/memory/jemalloc/jemalloc.c:3957 #4 0x080596f3 in imalloc (size=24) at /mozilla/memory/jemalloc/jemalloc.c:3974 #5 0x0805e42b in malloc (size=24) at /mozilla/memory/jemalloc/jemalloc.c:5992 #6 0xb71ccd47 in operator new () from /usr/lib/libstdc++.so.6 #7 0xb7c5e72a in ?? () #8 0xb7c60729 in ?? () #9 0xb7c58671 in ?? () #10 0xb7be48b0 in ?? () #11 0xb7c59119 in ?? () #12 0xb7b91c2c in ?? () #13 0xb7ed950f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #14 0xb70857ee in clone () from /lib/tls/i686/cmov/libc.so.6
Reporter | ||
Comment 3•16 years ago
|
||
(In reply to comment #2) > #3 0x080594a7 in arena_malloc (arena=0xb6c66040, size=24, zero=false) at > /mozilla/memory/jemalloc/jemalloc.c:3957 We're aborting at this line because this assertion fails: 3957 assert(arena->magic == ARENA_MAGIC); In my current GDB session, "arena->magic" is 2, whereas ARENA_MAGIC is #defined as 0x947d3d24. Link to code: http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/jemalloc.c#3957
Reporter | ||
Comment 4•16 years ago
|
||
I just tried this with jit disabled, and that didn't seem to affect anything. I also got a different stack in GDB this time: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb6ecb710 (LWP 26027)] 0xb8083430 in __kernel_vsyscall () (gdb) bt #0 0xb8083430 in __kernel_vsyscall () #1 0xb7134880 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7136248 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb717210d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb71783f4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xab90cfc5 in ?? () from /usr/lib/libGL.so.1 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) This looks scary.
Reporter | ||
Updated•16 years ago
|
Whiteboard: [sg:critical?]
Reporter | ||
Comment 5•16 years ago
|
||
Regression range: * NO CRASH: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre * CRASH: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021304 Minefield/3.0b4pre
Keywords: regressionwindow-wanted
Reporter | ||
Comment 6•16 years ago
|
||
Bonsai link: (with 1hr of buffer on either end) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-12+03%3A00%3A00&maxdate=2008-02-13+05%3A00%3A00&cvsroot=%2Fcvsroot
Reporter | ||
Comment 7•16 years ago
|
||
That range includes bug 417066 ("Enable jemalloc by default on Linux") which I'm most suspicious of right now... I'm building mozilla-central without jemalloc right now, to see if that fixes the crash.
Reporter | ||
Comment 8•16 years ago
|
||
Confirmed that this was caused by bug 417066. I tried building with --disable-jemalloc, and that fixed this crash. I also tried building without the MOZ_MEMORY=1 from attachment 302879 [details] [diff] [review] (as in http://hg.mozilla.org/try/rev/153a9b4d7b55 ), and that fixes this crash as well.
Blocks: 417066
Summary: Nightly build crashes when full-screening a YouTube video → Firefox w/ jemalloc crashes when full-screening YouTube video
Reporter | ||
Updated•16 years ago
|
Flags: blocking1.9.1?
Comment 9•16 years ago
|
||
sounds like a flash bug :/ not sure how to diagnose much further though. jemalloc does support valgrind though
Comment 10•16 years ago
|
||
If it's a flash bug then why would it be affected by whether firefox uses jemalloc or not?
Comment 11•16 years ago
|
||
different allocators lay out their memory differently. they handle double frees differently. flash overwriting some extra bytes with one allocator might be fine but might overwrite critical jemalloc tables telling the allocator what to do. They could also be allocating with one allocator and freeing with another as we've seen several binary extensions do.
Reporter | ||
Comment 12•16 years ago
|
||
FWIW, I can reproduce this 100% reliably on my 2 desktop machines, but never on my laptop. All 3 machines are running the same software (Ubuntu 8.10 / mozilla-central up-to-date nightly / Flash 10.0 rc12), so I'm not sure what the difference is.
Comment 13•16 years ago
|
||
This looks like an allocator mismatch in the flash plugin, not blocking the release on this.
Flags: blocking1.9.1? → blocking1.9.1-
Reporter | ||
Comment 14•16 years ago
|
||
fwiw, I still see this bug, using: - up-to-date mozilla-central debug build (at revision 38c24ab6f2a0 ) - Flash 10.0 r15 / flashplugin-nonfree package ver. 10.0.15.3ubuntu1~intrepid1 Hopefully Adobe can get someone to investigate this...
Updated•15 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?] Flash bug?
Reporter | ||
Comment 15•15 years ago
|
||
See also bug 479199, which looks similar, but uses hulu instead.
Reporter | ||
Comment 16•15 years ago
|
||
(In reply to comment #12) > FWIW, I can reproduce this 100% reliably on my 2 desktop machines, but never on > my laptop. Now that I think of it, this could feasibly be graphics-card-related -- my (working) laptop has an ATI graphics card, but my (crashing) desktops both have NVIDIA cards.
Reporter | ||
Comment 17•15 years ago
|
||
This looks the same as 469439 -- both are crashes that require nvidia drivers, jemalloc, and full-screen flash.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Group: core-security
Whiteboard: [sg:critical?] Flash bug? → [sg:dupe 469439]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•