If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[OOPP] Heap Corruption with Flash




6 years ago
5 years ago


(Reporter: bc, Assigned: khuey)


(Blocks: 1 bug)

Windows XP

Firefox Tracking Flags

(firefox6- wontfix, firefox7- wontfix, firefox8- wontfix, firefox9- wontfix, firefox10 wontfix)


(Whiteboard: [sg:critical])


(9 attachments)



6 years ago
Created attachment 552685 [details]
log of running the urls in windows xp

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:








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?

Comment 2

6 years ago
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.

Comment 3

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

Comment 4

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

Comment 5

6 years ago
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)


Comment 6

6 years ago
Created attachment 553193 [details]
crash report 1

This is the most common crash stack

Comment 7

6 years ago
Created attachment 553194 [details]
crash report 2

Comment 8

6 years ago
Created attachment 553195 [details]
crash report 3

Comment 9

6 years ago
Created attachment 553197 [details]
crash report 4

Comment 10

6 years ago
Created attachment 553198 [details]
crash report 5

Comment 11

6 years ago
Created attachment 553199 [details]
crash report 6

Comment 12

6 years ago
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.
Summary: Assertion failure: !threadData.conservativeGC.requestThreshold | Heap Corruption → Flash Heap Corruption with OOP


6 years ago
Component: General → Plug-ins
Keywords: assertion, hang
QA Contact: general → plugins
Summary: Flash Heap Corruption with OOP → [OOPP] Heap Corruption with Flash

Comment 13

6 years ago
The debug heap assertion is reproducible in these urls but I can't reproduce with locally saved versions:




Comment 14

6 years ago
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.

Comment 15

6 years ago
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.

Comment 17

6 years ago
(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.

Comment 18

6 years ago
Created attachment 553961 [details]
sample purify report

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.

Comment 19

6 years ago
Created attachment 554039 [details]

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.
Whiteboard: [sg:critical?]

Comment 21

6 years ago
we are looking into a similar/related issue in:

i was able to repro an access violation and our internal bug, #2875277, it is being assigned for investigation.


6 years ago
status-firefox6: --- → wontfix
status-firefox7: --- → wontfix
status-firefox8: --- → affected
status-firefox9: --- → affected
tracking-firefox6: --- → -
tracking-firefox7: --- → -
tracking-firefox8: --- → +
tracking-firefox9: --- → +

Comment 22

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

Comment 23

6 years ago
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 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.

Comment 24

6 years ago
(In reply to Bob Clary [:bc:] from comment #22)
> Sal, Werner: I still see these with Flash 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...

Comment 25

6 years ago
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.

Comment 26

6 years ago
i'll post your comment and make sure your pain points are noted.  thanks...
smadayag, any updates on your end here?

Comment 28

6 years ago
peter is assigned to investigate more into the issue in the Brannan release.  he is cc'd in this bug.
Assignee: nobody → pgrandma


6 years ago
status-firefox10: --- → affected
status-firefox8: affected → wontfix
tracking-firefox10: --- → +

Comment 29

6 years ago
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?
status1.9.2: --- → wontfix


6 years ago
Assignee: pgrandma → dveditz

Comment 30

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

Comment 31

6 years ago
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!
Assignee: dveditz → pgrandma
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.
status-firefox11: --- → affected
status-firefox9: affected → wontfix
tracking-firefox11: --- → +

Comment 34

6 years ago
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?
status-firefox12: --- → affected
tracking-firefox12: --- → +
tracking-firefox8: + → -
tracking-firefox9: + → -
Whiteboard: [sg:critical?] → [sg:critical]

Comment 35

6 years ago
Peter, any update here?

Taking this bug myself to track a resolution.
Assignee: pgrandma → joshmoz

Comment 36

6 years ago
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.

Comment 37

6 years ago
If we're waiting on khuey then I'm assigning these bugs to him.
Assignee: joshmoz → khuey
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?


6 years ago
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 657588
Untracking for akeybl.
status-firefox10: affected → wontfix
status-firefox11: affected → fixed
status-firefox12: affected → fixed
tracking-firefox10: + → ---
tracking-firefox11: + → ---
tracking-firefox12: + → ---
[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.
tracking-firefox-esr10: --- → 11+
tracking-firefox-esr10: 11+ → ---
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.
status1.9.2: wontfix → ---
status-firefox11: fixed → ---
status-firefox12: fixed → ---
Group: core-security
You need to log in before you can comment on or make changes to this bug.