479199 - Abort [@ libc-2.8.90.so@0x2d267 ] when viewing embedded hulu video on Linux.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Daniel Holbert [:dholbert]]

STEPS TO REPRODUCE:
 1. Load URL, http://blog.hulu.com/2009/2/9/grammys
 2. Click "play" in the embedded hulu video

ACTUAL RESULTS:
Immediate abort, with this output printed to my terminal in debug builds:

*** glibc detected *** ./dist/bin/firefox-bin: munmap_chunk(): invalid pointer: 0xa1efe220 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb71e1454]
/usr/lib/libGL.so.1[0xa7d8afc5]
======= Memory map: ========
08048000-08063000 r-xp 00000000 08:11 20578417   /scratch/work/builds/mozilla-central/mozilla-central.09-02-03.11-36/obj/dist/bin/firefox-bin
(lots more lines like the above one)

Crash reports: 
http://crash-stats.mozilla.com/report/index/9f6aac17-c850-4689-a40a-095f12090218?p=1
http://crash-stats.mozilla.com/report/index/4408fd7d-74c9-4c2f-b431-300532090218?p=1

VERSION INFO:
 - Ubuntu 8.10 up-to-date on a x86 machine
 - about:plugins shows that I have Flash version 10.0 r15.
 - Firefox builds: I've reproduced this with this morning's mozilla-central nightly...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090218 Minefield/3.2a1pre
    ... and also with my mozilla-central debug build, at revision 1b6278ecd0d7.

Flagging as security-sensitive, because this looks like memory corruption, which is scary.

Comment 1

[Daniel Holbert [:dholbert]]

FWIW, if I directly load the embedded video via the url in the page's "<embed>" tag ( http://www.hulu.com/embed/nTZp_yqVQvn6rUAhVq4v0g ), it plays fine.  But then, after playing it directly, I can still go back to the blog post with the embedded video and click play there, and it aborts.

Comment 2

[Daniel Holbert [:dholbert]]

This bug  sounds like it could be another issue with Flash not getting along with jemalloc, like bug 466388.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did you see what valgrind says?  (That said, comment 2 sounds likely.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: valgrind output

I'm attaching a log of valgrind output, generated from running
   ./dist/bin/firefox -profile deleteme -no-remote -g -d valgrind

The log starts when I click the "play" button on the embedded video (which triggers the abort).

The first few lines are:
==2918== Mismatched free() / delete / delete []
==2918==    at 0x4024B4A: free (vg_replace_malloc.c:323)
==2918==    by 0x13B51FC4: (within /usr/lib/libGL.so.177.82)
==2918==  Address 0xd233760 is 0 bytes inside a block of size 32 alloc'd
==2918==    at 0x8059592: arena_malloc_small (jemalloc.c:3944)
==2918==    by 0x8059A1F: arena_malloc (jemalloc.c:4004)
==2918==    by 0x8059B25: imalloc (jemalloc.c:4016)
==2918==    by 0x805E9F7: malloc (jemalloc.c:6043)
==2918==    by 0x4EAF05F: strdup (in /lib/tls/i686/cmov/libc-2.8.90.so)
==2918==    by 0x13B51F4C: (within /usr/lib/libGL.so.177.82)

So it looks like we end up calling the "free" function defined in vg_replace_malloc.c (non-Mozilla code) to clean up memory that was allocated via the "malloc" function defined in jemalloc.c (Mozilla code).

Notice that both calls trace back to the "/usr/lib/libGL.so.177.82" library, which seems strange to me....  I'd imagine that a particular library would be consistent in its selection of malloc/free methods, but it's apparently not in this case, for some reason.

Comment 5

[Daniel Holbert [:dholbert]]

Here's a list of all crashes with this failure within the past 2 weeks:

http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=libc-2.8.90.so%400x2d267&date=&range_value=2&range_unit=weeks&do_query=1&signature=libc-2.8.90.so%400x2d267

I think there's ~160 reports in that list, and the comments pretty much all mention flash videos (& sometimes full-screening them, like in bug 466388)

Comment 6

[Karl Tomlinson (:karlt)]

Comment 4 indicates that this is a dupe of bug 493541, and so should now be fixed, but the fix can only be verified on the URL here from a US ip address.