Look for MSCRT ASSERTION: dbgheap.c(1279) : Assertion failed: _CrtIsValidHeapPointer(pUserData) in the attached log. I've seen Assertion failure: !threadData.conservativeGC.requestThreshold on beta, aurora, nightly on Windows on the following urls in automation: http://blog.techsatish.net/2011/08/nadhaswaram-04-08-11.html http://dedepurnama.blogspot.com/2009/08/smadav-rev-6-antivirus-portable.html http://www.bursalagu.com/download-mp3/NHNoYXJlZC5jb20.-czRMVmcyWkYvTGFndV9TdW5kYS1XaW5hXy1fU3VyZ2FfTmFfRGFt-lagu_sunda_%252C_wina_%252C_surga_na_dampal_sampean_indung.mp3.html http://film-ddl.blogspot.com/2011/06/regarder-film-sans-identite-vostfr-en.html http://autoptp.eu/promo-benef/?id=4204 http://beeg.com/free/hot-italian-secretary-having-anal-sex/footer%26p= http://kingtube.web.fc2.com/webs/ Locally on Windows XP the assertion has been hard to reproduce reliably. In the attached log: heap corruption on http://blog.techsatish.net/2011/08/nadhaswaram-04-08-11.html (reproducible >~ 50% of the time) the assertion on http://dedepurnama.blogspot.com/2009/08/smadav-rev-6-antivirus-portable.html (reproducible ~ 10% of the time) hang in firefox in http://autoptp.eu/promo-benef/?id=4204 (reproducible 100% of the time) This may be related to bug 660787 since some of these sites also have the "download now" / "you are a winner" s(p|c)ams. Filing under Core:General since I don't really know what is happening here.

Is this a regression?

I don't know. I've seen this randomly over at least a month but haven't been able to pin point what is happening as it is difficult to reproduce the assertion in general. I decided to dedicate a chunk of time yesterday and today into trying to figure it out and even if I failed to get good steps to reproduce or a good bug report going a head and filing the bug to get it on the radar.

fwiw, i'm running http://blog.techsatish.net/2011/08/nadhaswaram-04-08-11.html under purify atm.

and of course, purify crashes running that page. :/

I started running the automation with the patch from bug 587982 applied which aborts when the crt heap is corrupted. I see crashes in the flash plugin-container for: (warning blogdelnarco can contain violent images) http://www.ceropeliculasmegavideo.net/search?updated-max=2011-07-17T18%2525253A14%2525253A01-04%2525253A30%252526max-results=42%252526popening=2 http://www.blogdelnarco.com/2011/08/capturan-tres-integrantes-de-los-zetas.html http://www.disney.com.br/disneyjunior/shows/osimaginadores/index.html http://www.streamiz.com/index.php http://www.blogdelnarco.com/2011/07/destazan-brutalmente-hombre-en-morelos.html#more http://animeid.com/anime/naruto-shippuden.html http://telenovelas.darkiller.com/2011/07/la-fuerza-del-destino-capitulo-92.html http://www.todoanimes.com/detective-conan/31/ http://www.wattpad.com/1376762-v%25E1%25BB%25A5-c%25C3%25A1-c%25C6%25B0%25E1%25BB%25A3c-t%25C3%25ACnh-y%25C3%25AAu-full?p=50 http://blog.techsatish.net/2011/08/nadhaswaram-04-08-11.html http://animeid.com/ver/naruto-shippuden-224.html

This is the most common crash stack

Following wsharp's idea, I retested the urls in comment 5 on Windows XP with ipc plugins turned off and *did not experience the debug heap assertion*. I turned ipc plugins back on and reproduced the debug heap assertions. I'm dropping the assertion from this bug and focusing it solely on the heap corruption.

The debug heap assertion is reproducible in these urls but I can't reproduce with locally saved versions: http://adserver.adtechus.com/adiframe/3.0/5180/1789124/0/170/ADTECH;target=_blank;sub1=2001;sub2=xusrb200;sub3=vm;sub4=xusrb200-p1842767-v3883995-sl437954 http://adserver.adtechus.com/adiframe/3.0/5180/1789124/0/170/ADTECH;target=_blank;sub1=2001;sub2=xusrb200;sub3=vm;sub4=xusrb200-p1873732-v5568679-sl437954 http://adserver.adtechus.com/adiframe/3.0/5180/1789124/0/170/ADTECH;target=_blank;sub1=2001;sub2=xusrb200;sub3=vm;sub4=xusrb200-p805034-v7557936-sl437954

Diagnosing this will require valgrind/purify, or maybe record/replay with Flash symbols. By the time you hit the memory assertion you've lost the state which might point to a specific cause.

Yeah, I tried purify on some of the original urls but it crashed. :-( I'm scanning through all of the subsidiary urls loaded by the original urls (that's where the ad urls came from) and plan on trying purify on them asap. I suppose I could try valgrind+wine+firefox too.

is this at all related to bug 641226? That, too, showed heap corruption.

(In reply to Daniel Veditz from comment #16) > is this at all related to bug 641226? That, too, showed heap corruption. It may well be. There are a couple of urls in common. Now that we have the debug heap abort I'll retest all the fatalerror urls and see how it turns out.

Firefox crashes under purify but here is a sample report none-the-less. There are Invalid pointer write in pixman_implementation_create_sse2 errors but they are not specific to this bug.

Valgrind under Linux doesn't show anything that might be corrupted memory but there are a number of ==5210== Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to uninitialised byte(s) ==5210== at 0x3CB908: sendmsg (in /lib/libpthread-2.13.so) ==5210== by 0x5AC78AF: IPC::Channel::ChannelImpl::Send(IPC::Message*) (ipc_channel_posix.cc:707) messages with varying locations for the uninitialized data. Attaching a log for your viewing pleasure.

Either way this doesn't look good, the only question is whether this is our bug or Flash stomping on our memory.

we are looking into a similar/related issue in: https://bugzilla.mozilla.org/show_bug.cgi?id=657588 i was able to repro an access violation and our internal bug, #2875277, it is being assigned for investigation.

Sal, Werner: I still see these with Flash 10.3.183.10 I can not find internal bug 2875277 in your instance of jira. What is the status here?

http://www.lgmobile.co.kr/cyon/web/product/detail/viewProductDetail.dev?product_id=372 on Firefox 1.9.2 Windows XP debug build with Flash 10.3.183.10 which doesn't have my mscrt abort patch applied. May need to reload. I wasn't able to reproduce on Nightly or Beta. Debug Error: Heap Corruption detected: after normal block (#blah) at 0xblah. CRT detected that the application wrote to memory after end of heap buffer.

(In reply to Bob Clary [:bc:] from comment #22) > Sal, Werner: I still see these with Flash 10.3.183.10 I can not find > internal bug 2875277 in your instance of jira. What is the status here? the number is in reference to our internal bug. i've sent the bug for another review since our dev could not reproduce. hopefully the review board should assign someone to contact you directly on the issue. i'll keep you posted...

Sal, please tell them that I have been seeing these Flash related heap corruption bugs for a long time. In addition I see a number of other crashes with different signatures. I am quite frustrated that some anonymous dev says "I can't reproduce" when these problems appear regularly. If they can't reproduce these please have them contact me directly either at my bugmail bclary@bclary.com or at my work address bclary@mozilla.com. Our users are extremely frustrated due to Flash crashes and many of them blame Firefox for the repeated crashes which seem never to be fixed. It bugs me to no end to see release after release of Flash without the crashes which affect Firefox being fixed.

i'll post your comment and make sure your pain points are noted. thanks...

smadayag, any updates on your end here?

peter is assigned to investigate more into the issue in the Brannan release. he is cc'd in this bug.

Sorry for my silent treatment, I was asked to look into something else for a week (which turned into two). I can't help but notice the common thread in the crash reports Bob uploaded is the thread with flash looks like: 0 ntdll.dll + 0xe514 1 ntdll.dll + 0x1045 2 msvcr80d.dll + 0x1b146 3 msvcr80d.dll + 0x1b0c6 4 mozalloc.dll!moz_realloc [mozalloc.cpp : 142 + 0xd] 5 xul.dll!Pickle::Resize(unsigned int) [pickle.cc : 519 + 0xf] 6 xul.dll!Pickle::Pickle(int) [pickle.cc : 46 + 0x9] 7 xul.dll!IPC::Message::Message() [ipc_message.cc : 22 + 0x15] 8 xul.dll!mozilla::ipc::RPCChannel::Call(IPC::Message *,IPC::Message *) [RPCChannel.cpp : 219 + 0xa] 9 xul.dll!mozilla::plugins::PPluginModuleChild::CallNPN_UserAgent(nsCString *) [PPluginModuleChild.cpp : 267 + 0x15] 10 xul.dll!mozilla::plugins::PluginModuleChild::GetUserAgent() [PluginModuleChild.cpp : 680 + 0x10] 11 xul.dll!mozilla::plugins::child::_useragent [PluginModuleChild.cpp : 1256 + 0xb] 12 NPSWF32.dll + 0x1933de while the thread that crashes is crashing in the allocator, coupled with the comment this goes away when ipc plugins turned off (8/15). How likely is it that the Resize() isn't thread safe?

I see you've marked this won't fix. I assume that means you don't want me to work on it?

Hi Peter: We marked this "won't fix" in the next shipping Firefox because we don't have a fix to take. This one is a real problem with Flash Player and Firefox and really needs to be investigated. We won't be able to do that on this side without debugging the Flash sources so I'm reassigning to you. Thanks!

I "wontfixed" for the 1.9.2 branch because I expect Firefox 3.6.x will be EOL by time this gets fixed in Flash. The bug status as a whole is definitely not WONTFIX!

Peter, any updates on the Adobe side of this yet? I don't see how whether our Resize() method being thread safe has anything to do with this crash. All the relevant NPAPI calls (with the exception of one) are main thread only (where main thread means the thread that created the plugin instance), meaning that if they're ever called on a thread other than the main thread then that's a bug in the plugin.

Johnny, I would agree with your point, but I'm unclear how this is arranged now that the plugin's are in a container process separate from the main thread of the browser process. Is the mozalloc.dll memory shared across the browser's threads and processes, or is it unique to the specific plugin-container.exe?

Peter, any update here? Taking this bug myself to track a resolution.

This is likely to be related to the heap corruption seen in bug 657588, which khuey has captured in recording but not yet analyzed. I'd really like to see if we can get that finished.

If we're waiting on khuey then I'm assigning these bugs to him.

bc is going to run automation with the patch in bug 657588 and see if this reproduces.

bc, can we dupe this to Bug 657588?

Untracking for akeybl.

[Triage comment] This bug is being tracked for landing on ESR branch. Please land patches on http://hg.mozilla.org/releases/mozilla-esr10/by Thursday March 1, 2012 in order to be ready for go-to-build on Friday March 2, 2012. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more information.

How is this marked a duplicate of bug 657588 and also marked fixed in branches without a checkin?

Just ignore it, the relevant stuff if in Bug 657588.