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.
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.
This bug sounds like it could be another issue with Flash not getting along with jemalloc, like bug 466388.
Did you see what valgrind says? (That said, comment 2 sounds likely.)
Created attachment 363737 [details] 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.
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 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.