#11 in top crashers for 3.5.4 on Mac OS X: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.4&platform=mac&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=TextRunWordCache%3A%3ACacheHashEntry%3A%3AKeyEquals%28TextRunWordCache%3A%3ACacheHashKey%20const*%29%20const TextRunWordCache::CacheHashEntry::KeyEquals const gfxFont.h:1098 SearchTable pldhash.c:423 PL_DHashTableOperate pldhash.c:645 TextRunWordCache::LookupWord nsTHashtable.h:188 TextRunWordCache::MakeTextRun gfx/thebes/src/gfxTextRunWordCache.cpp:761 gfxTextRunWordCache::MakeTextRun gfx/thebes/src/gfxTextRunWordCache.cpp:1003 BuildTextRunsScanner::BuildTextRunForFrames layout/generic/nsTextFrameThebes.cpp:431 BuildTextRunsScanner::FlushFrames layout/generic/nsTextFrameThebes.cpp:1183 nsTextFrame::EnsureTextRun layout/generic/nsTextFrameThebes.cpp:1114 nsTextFrame::PaintText layout/generic/nsTextFrameThebes.cpp:4502 nsDisplayText::Paint layout/generic/nsTextFrameThebes.cpp:3778 nsDisplayList::Paint const layout/base/nsDisplayList.cpp:313 nsDisplayClip::Paint layout/base/nsDisplayList.cpp:978 nsDisplayList::Paint const layout/base/nsDisplayList.cpp:313 nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1114 PresShell::Paint layout/base/nsPresShell.cpp:5775 nsViewManager::RenderViews view/src/nsViewManager.cpp:648 nsViewManager::Refresh view/src/nsViewManager.cpp:512 nsViewManager::DispatchEvent view/src/nsViewManager.cpp:1153 HandleEvent view/src/nsView.cpp:168 nsChildView::DispatchEvent widget/src/cocoa/nsChildView.mm:2042 nsChildView::DispatchWindowEvent widget/src/cocoa/nsChildView.mm:2055

Can you get some crash URLs from choffman and see if any are reproducible?

looks like this might be harder to reproduce. not many crashes on session restore or back to back visiting of pages 253 total crashes for TextRunWordCache::CacheHashEntry::KeyEquals on 20091106-crashdata.csv 8 start up crashes inside 3 minutes types of sites 229 http: 16 \N 3 about:blank 2 https: 2 about:sessionrestore 1 about:cache?device=disk domains of sites 45 http://www.youtube.com 16 \N// 15 http://www.facebook.com 8 http://video.google.com 7 http://apps.facebook.com 6 http://watch.ctv.ca 5 http://www.megavideo.com 5 http://www.hulu.com 4 http://www.xvideos.com 4 http://mail.google.com 3 http://video.google.ca 3 about:blank// os breakdown 190 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.11 8S2167 26 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Service Pack 3 16 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Service Pack 2 2 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.9 8P2137 2 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.11 8S165 2 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 6.1.7600 1 memcmp | TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Service Pack 3 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.5.8 9L31a 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.5.8 9L30 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.5.7 9J61 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.9 8P4112 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.8 8N1150 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.8 8L2127 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.7 8K1106 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.10 8R3025 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.10 8R2232 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const*) const Mac OS X 10.4.10 8R2218 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 6.0.6001 Service Pack 1 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Szervizcsomag 2 1 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Dodatek Service Pack 2 1 @0x0 | TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const* const) Windows NT 5.1.2600 Service Pack 3 distribution of all versions where the TextRunWordCache::CacheHashEntry::KeyEquals crash was found on 20091106-crashdata.csv 88 Firefox 3.5.5 86 Firefox 3.5.4 37 Firefox 3.0.15 13 Firefox 3.5.3 5 Firefox 3.6b1 5 Firefox 3.5.2 4 Firefox 3.0.10 4 Firefox 3.0.1 2 Firefox 3.5 1 Firefox 3.7a1pre [and other releases back to 3.0]

This is also showing up on 1.9.0, #15 Mac as of today: http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.0.15&platform=mac&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1 (Curiously, we don't see this in Camino at all.) Also, fixing the summary so that Socorro with match it (alas, bug 502820 sucks :/ ).

(In reply to comment #2) > looks like this might be harder to reproduce. not many crashes on session > restore or back to back visiting of pages > will hammering on this, lets see what i can do with steps to reproduce !

The code in TextRunWordCache::CacheHashEntry::KeyEquals compares the key text to the textrun text using the length of the key but it never checks to assure that the key length is shorter than the textrun length: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/gfxTextRunWordCache.cpp#899 This rarely occurs but I tested and it can occur. Loading the HTML5 spec, below are the cases where the textrun length is less than the key length: keyequals textrun 2 (1) key 3 (2) textrun: sx key: r keyequals textrun 2 (1) key 17 (1) textrun: , key: (space-B-space-B) I think it would make sense to simply bail immediately when the textrun text length is less than the key length.

IsWordEnd would return false if mWordOffset + aKey->mLength > mTextRun->GetLength(), so we should already bail. Or am I missing something?

(In reply to comment #8) > IsWordEnd would return false if mWordOffset + aKey->mLength > > mTextRun->GetLength(), so we should already bail. Or am I missing something? Yeah, so it's not that simple. The crash stack crawl shows TextRunWordCache::CacheHashEntry::KeyEquals const gfxFont.h:1098 which is at http://hg.mozilla.org/releases/mozilla-1.9.1/file/49342a1d9d93/gfx/thebes/public/gfxFont.h#l1098 const PRUnichar GetChar(PRUint32 i) const { return (mFlags & gfxTextRunFactory::TEXT_IS_8BIT) ? mText.mSingle[i] : mText.mDouble[i]; } So it would seem that KeyEquals() calls the static method IsWordEnd() which calls the GetChar() method of the text run where the crash occurs. Guessing the text run has somehow already been deleted.

Possibly related crashes: 3.5.5 http://crash-stats.mozilla.com/report/index/f09b8ff0-40fa-4f77-8828-4d0d92091123 GetWordFontOrGroup gfx/thebes/src/gfxTextRunWordCache.cpp 297 TextRunWordCache::RemoveWord(gfxTextRun *,unsigned int,unsigned int,unsigned int) gfx/thebes/src/gfxTextRunWordCache.cpp 822 TextRunWordCache::RemoveTextRun(gfxTextRun *) gfx/thebes/src/gfxTextRunWordCache.cpp 853 FrameTextRunCache::RemoveFromCache(gfxTextRun *) layout/generic/nsTextFrameThebes.cpp 383 FrameTextRunCache::NotifyExpired(gfxTextRun *) layout/generic/nsTextFrameThebes.cpp 390 3.6 http://crash-stats.mozilla.com/report/index/84c639e3-2475-4f55-b3bf-537372091123 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const * const) gfx/thebes/src/gfxTextRunWordCache.cpp 912 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const * const) PL_DHashTableOperate|hg:hg.mozilla.org/releases/mozilla-1.9.2:obj-firefox/xpcom/build/pldhash.c 661 TextRunWordCache::CacheHashEntry::KeyEquals(TextRunWordCache::CacheHashKey const * const) TextRunWordCache::MakeTextRun(unsigned char const *,unsigned int,gfxFontGroup *,gfxTextRunFactory::Parameters const *,unsigned int) gfx/thebes/src/gfxTextRunWordCache.cpp 761

More possibilities: http://crash-stats.mozilla.com/report/index/d53e36a2-8758-484d-a8bc-7c18d2091123 http://crash-stats.mozilla.com/report/index/4adac664-350d-4ecd-8a76-f5ce72091123 http://crash-stats.mozilla.com/report/index/5f5f1564-3f15-4f52-a459-5d37f2091123 http://crash-stats.mozilla.com/report/index/8e6c7b8d-9cd0-4bb2-9e3f-f49e82091123

Searching around for other patterns. Mac crashes seem to be entirely on 10.4.x: Sample of 500 Mac versions of this crash: 10.4.10 5 10.4.11 483 10.4.7 2 10.4.8 7 10.4.9 2 10.6.2 1 Associated versions of Flash (10.0.32.18 is the latest) 025105C956638D665850591768FB743D0 5 10.0.32.18 on ppc 2E4EE5C06F4841828F99C9FB6F29A5840 1 38AEB67F6A0B43C6A341D7936603E84A0 6 10.0.12.36 on x86 77CB5AC61C456B965D0B41361B3F6CEA0 1 10.0.22.87 on ppc 860692A215F054B7B9474B410ABEB5300 91 10.0.22.87 on x86 B19EE2363941C9582E040B99BB5E237A0 392 10.0.32.18 on x86 CF7A0D2CC2664865921FD463FC8121020 2 D9333406A9F865BA9A6A1C57FA3487F70 2 Comments suggest something to do with full-screen video, lots of comments about "while playing YouTube full-screen": - I was on Facebook clicking on a link when Firefox shut down. - I just finished watching a movie video in YouTube when Firefox shut down. - watching flash movie - Firefox keeps crashing when I am using video chat in Gmail - Firefox closed by itself - I was watching a video on the PBS site for Bill Moyers' program. - it just stopped http://www.youtube.com/watch?v=G6nmnKMZRSY - watching streaming news video on ctv.ca - once again, watching a video on YouTube. only crashes when watching videos - 2nd time firefox crashes in 20 minutes - Listening to an audio clip on SFOpera.com it quit when I tried to - Went to maximize a video and it crashed. Been crashing quite a bit lately. Pretty annoying actually. Is it because I have too many browser tabs open? - watching programme on TvShack, when firefox crashed - i was on megavideo.com - youtube video to fullscreen - crashes mostly while watching a video on youtube - www.hulu.com keeps shutting down. - trying to watch tv - watching god damn youtube. is it too much to ask for the bitch not to crash??? - watching a video and it crashed - I was watching multiple videos on youtube. - was playing farmville then it suddenly went off - whacthing videos on youtube - whacthing videos on youtube - watching video - my show ended on hulu and everything closed - watching video on you tube - I was just loading a video on Youtube when it crashed. I had a bunch of other tabs open too though. - youtube keeps crashing - Flash video player on nba.com. Video fully loaded. During playback, always crashes!! - watching abc fmily and playing face book - trying to watch a video through Google video - watched to the end of a flash-based video. Firefox then suddenly quit - every ten fucking minutes, do something, you fucks - Watching a show on Hulu.com. This is the upteenth time it's crashed while doing this. Very irritating - I was playing video (vimeo) in a website - I was watching the show "Private Pratice" on line - fucking youtube - any time you watch videos off of this site it will eventually lead to a crash. http://tv.blinkx.com/. Usually happens as you watch a series of episodes. By the time you launch and play 8-10 videos, a crash will happen, mostly when the video is paused and you are looking at some other tab in the browser. - I was simply watching a video online and the page crashed. - It keeps quitting when I'm hulu.... its freaking annoying. - Camino froze up. Was trying to watch a You Tube video. - liebes mozilla-team, irgendwas stimmt hier nicht. während es früher nur sehr selten auftrat, dass firefox auf meinem rechner abstürzte, passiert das derzeit beinahe täglich, vor allem dann, wenn ich youtube nutze.was kann der grund hierfür sein? ich bitte dringend um eine antwort. mit freundlichen grüßen, ioannis christoforidis - watching video on TED - youtube.com/watch?v=0ltAGuuru7Q trying to find cursor so to select one of the suggested videos offered at the end of the above video hit escape to go to smaller vid screen, hit enlarge button, clicked on one of the suggested videos firefox crashed then it restarted on the previously played video, by itself, before this reporter box opened - espn360 loading when it crashed - playing you tube video - Crashed about 10 seconds after a I'd unpaused a full-screened YouTube playback - watching ny times video, full screen clicked esc. - Viewing YouTube video - watching Grey's Anatomy, Season 6 Episode 10 on CTV - I was on YouTube watching music videoes - I tried scrolling down with the wheel on my mouse. 3 other tabs were open in addition to the one I was reading. - Watching MSN Videos - Camino a téléchargé une vidéo en streaming, la vidéo est en pause. Mise en veille de l'ordinateur par fermeture de l'écran (ordinateur portable). Réouverture de l'écran et sortie de veille de l'ordinateur. Clique sur la vidéo pour la visionner. -> plantage! - I was watching a video on Hulu. This happens often when I am on that website. - was watching streaming video from a network website when Firefox crashed. - I was doing fantastic things with Youtube and your browser crashed. This makes me sad inside. Now I will drink more whiskey and it's your fault. Stochastic.

Running with 3.5.5 on Mac OS X 10.4.11 (x86) I was able to reproduce a set of crashes that look similar to the reported crashes, but I only crashed in KeyEquals once. Rough steps: 1. Open nba.com in a tab, start video running 2. Open youtube.com in a tab, start a video playing 3. Open nytimes.com in a tab and click on video clips (towards the bottom) 4. Open up various NY Times articles, click on flash banner ads 5. Iterate over the steps above, clicking making the videos full-screen, pausing, playing again. etc. This type of activity seems to generate a crash every 15-20 minutes or so. 3.5.6pre build, was not able to reproduce problem(!), although it's hard to assert that the problem is somehow "fixed" in 3.5.6 given that I'm not really sure yet how to reproduce this consistently. Out of five crashes, one was in the KeyEquals call.

Huh. So it seems somehow correlated to Flash, but is actually crashing in our code? I'd be interested to know what the other stacks were that you crashed in and how they rate in the topcrash list.

John, have you tried reproducing it with Windows at all? If we can reproduce this in a VMWare recording environment, we can probably figure it out. But that only works with Windows guests.

Another thing that would be great is if we had test automation that could browse randomly around to reproduce this and other "long running" crashes. Then we could run it under recording and probably debug the crashes even if we don't have real steps to reproduce.

Bob, see comment #16.

The top-site testing covers a great deal of the goal in comment 16. The current automation project is geared primarily for looking at specific urls from the crash reports, but the general tool can spider arbitrary sets of urls and could report its results to the same database.

Chris P said he couldn't reproduce it in our VM environment. I'll have a bash at it myself. This is with a trunk build --- I see one crash reported in the last week at KeyEquals on Windows trunk.

I played around with the Windows 3.5.5 release build in the VM trying the things in comment #40 for over half an hour and couldn't get it to crash.

(In reply to comment #14) > Huh. So it seems somehow correlated to Flash, but is actually crashing in our > code? I'd be interested to know what the other stacks were that you crashed in > and how they rate in the topcrash list. These are the crashes I saw with 3.5.5 on 10.4.11, only the first one is in TextRunWordCache code: http://crash-stats.mozilla.com/report/index/bp-7fc5bd55-a18a-42bf-8f33-054e72091126 http://crash-stats.mozilla.com/report/index/bp-7dba540b-fc62-42af-9c44-db4042091126 http://crash-stats.mozilla.com/report/index/bp-6e875324-395a-479d-8882-93bff2091126 http://crash-stats.mozilla.com/report/index/bp-74467e9a-a0c9-463f-8176-3aa112091126 Other crashes: 0 @0x0 1 nsRuleNode::DestroyInternal layout/style/nsRuleNode.cpp:661 2 nsRuleNode::DestroyInternal layout/style/nsRuleNode.cpp:656 3 nsStyleSet::Shutdown layout/style/nsRuleNode.h:458 4 PresShell::Destroy layout/base/nsPresShell.cpp:1970 0 nsRuleNode::GetStyleVisibility layout/style/nsStyleStructList.h:103 1 nsStyleContext::GetStyleVisibility layout/style/nsStyleStructList.h:103 2 nsIFrame::IsVisibleForPainting eStructList.h:103 3 nsFrame::DisplayBorderBackgroundOutline layout/generic/nsFrame.cpp:972 0 nsIFrame::BuildDisplayListForChild layout/generic/nsFrame.cpp:1431 1 DisplayLine layout/generic/nsBlockFrame.cpp:6078 2 nsBlockFrame::BuildDisplayList layout/generic/nsBlockFrame.cpp:6157 (In reply to comment #15) > John, have you tried reproducing it with Windows at all? > > If we can reproduce this in a VMWare recording environment, we can probably > figure it out. But that only works with Windows guests. I've tried but with no luck. If this is a memory stomping bug it may be that the exact set of steps is different across platforms because of the behavior of different allocators. I still haven't been able to reproduce this with my own build but I'm going to try that today under 10.4.11. I want to add extra validation code to the textrun code to hopefully catch when corruption is occurring.

Can you reproduce it on Mac with a clean test profile?

(In reply to comment #22) > Can you reproduce it on Mac with a clean test profile? I've only reproduced this on 10.4.11/x86, using a machine at home. I'll try to reproduce it using a clean profile tonight.

Does valgrind show anything interesting here?

(In reply to comment #9) > The crash stack crawl shows > > TextRunWordCache::CacheHashEntry::KeyEquals const gfxFont.h:1098 > > which is at > http://hg.mozilla.org/releases/mozilla-1.9.1/file/49342a1d9d93/gfx/thebes/public/gfxFont.h#l1098 > > const PRUnichar GetChar(PRUint32 i) const > { return (mFlags & gfxTextRunFactory::TEXT_IS_8BIT) ? mText.mSingle[i] : > mText.mDouble[i]; } > > So it would seem that KeyEquals() calls the static method IsWordEnd() which > calls the GetChar() method of the text run where the crash occurs. Guessing > the text run has somehow already been deleted. IsWordEnd() has already used aTextRun->GetLength() successfully, so it seems likely that the gfxTextRun has not been deleted, which suggests that the mText may have been deleted. A way of making this easier reproduce might be to add code to ~gfxTextRun to read the entire mText (thus checking that it is still accessible, or, with valgrind, allocated).

The module correlations list (*-interesting-modules.txt from http://people.mozilla.com/crash_analysis/ ) might be of interest. The top lines tend to be: 100% (122/122) vs. 14% (2453/17602) GLDriver 100% (122/122) vs. 14% (2453/17602) libGLSystem.dylib 100% (122/122) vs. 35% (6245/17602) FindByContent 100% (122/122) vs. 35% (6245/17602) WebServicesCore 100% (122/122) vs. 35% (6245/17602) libRaw.dylib 100% (122/122) vs. 35% (6246/17602) libJP2.dylib 100% (122/122) vs. 38% (6709/17602) GLRendererFloat 100% (122/122) vs. 38% (6715/17602) GLEngine but some of the lower bits may also be interesting. (That's saying that 100% of the people with this crash have those modules loaded, relative to 14%...38% of the total crash sample on Mac.) Note that flash does *not* show up in the module correlations.

(In reply to comment #26) > Note that flash does *not* show up in the module correlations. Er, sorry, I lied. Flash does show up; it's just near the bottom because 93% of our crashes on Mac have flash loaded, so it's only a 7% difference. (But it's also correlated with quicktime.)

If it's graphics drivers causing trouble, then it could well be that running in a VM is useless because the guest doesn't use those drivers. I suspect valgrind may be our best hope here right now.

I have played around with valgrind. Lots of good information, about all sorts of things that are probably Apple bugs. But I'm not sure if it's hooking into all the right memory allocation routines; with pages containing Flash it spews endless errors saying Flash is touching memory that has never been allocated on the heap or stack. My guess is that Flash is using some form of allocator that valgrind doesn't understand or know about. After loading a bunch of pages using Flash, valgrind crashes (i.e. not Firefox but valgrind itself). So I think valgrind itself will need some work before we can track down problems like this. One thing to note: valgrind only runs on 10.5, not 10.4 or 10.6. Unfortunately, this bug only seems to happen on 10.4, it almost never occurs on 10.5. Go figure.

(In reply to comment #25) > IsWordEnd() has already used aTextRun->GetLength() successfully, so it seems > likely that the gfxTextRun has not been deleted, which suggests that the mText > may have been deleted. > > A way of making this easier reproduce might be to add code to ~gfxTextRun to > read the entire mText (thus checking that it is still accessible, or, with > valgrind, allocated). I don't think GetLength() succeeding really tells you whether the gfxTextRun is alive or dead, only that the memory hasn't been overwritten. Going through the actual Windows minidumps, there are a number of places where it crashes, even though the crash report looks like the same place. But I do agree that the way to flush this out is with extra verification code, I think setting up guards and double-checking field validity in various ways is probably the best bet to flush out the cause of this.

I set up a bunch of pages that crudely iterate over a set of pages, some with lots of text, random blogs, pages with video, etc. The tests are here: http://people.mozilla.org/~jdaggett/memtesting/ To change the default cycle time: http://people.mozilla.org/~jdaggett/memtesting/iterateblogs.html#5000 This uses a cycle time of 5000ms. If I can't come up with a reproducible crash, I'm going to play with mozmill to see if I can force it by using a set of actions involving pages with Flash on them.

(In reply to comment #29) > I have played around with valgrind. Lots of good information, about all sorts > of things that are probably Apple bugs. But I'm not sure if it's hooking into > all the right memory allocation routines; with pages containing Flash it spews > endless errors saying Flash is touching memory that has never been allocated > on the heap or stack. My guess is that Flash is using some form of allocator > that valgrind doesn't understand or know about. After loading a bunch of > pages using Flash, valgrind crashes (i.e. not Firefox but valgrind itself). > So I think valgrind itself will need some work before we can track down > problems like this. We know someone who might be able to do something about that! > One thing to note: valgrind only runs on 10.5, not 10.4 or 10.6. > Unfortunately, this bug only seems to happen on 10.4, it almost never occurs > on 10.5. Go figure. Have you ever reproduced it on 10.5? Or are you basing that on crash-stats? Thanks for all your hard work on this!! Turns out that VMWare does support record and replay of apps that use D3D. However, if the bug is in the D3D driver(s), then we're not likely to see it in VMWare because they use their own driver. It's also possible that Flash uses driver blacklisting or whitelisting, or some other kind of hardware feature detection, and might not even take the D3D path when running with the VMWare driver.

John, are you running a debug build or an opt build to reproduce the crash? If a debug build, can you tell whether NS_ASSERTION(aTextRun->mCachedWords == 0) is firing in TextRunWordCache::RemoveTextRun? Knowing whether that fires or not when the bug occurs would be quite useful.

(In reply to comment #29) > I have played around with valgrind. Lots of good information, about all sorts > of things that are probably Apple bugs. But I'm not sure if it's hooking into > all the right memory allocation routines; with pages containing Flash it spews > endless errors saying Flash is touching memory that has never been allocated on > the heap or stack. My guess is that Flash is using some form of allocator that > valgrind doesn't understand or know about. After loading a bunch of pages > using Flash, valgrind crashes (i.e. not Firefox but valgrind itself). So I > think valgrind itself will need some work before we can track down problems > like this. Valgrind can handle custom allocators if the code is annotated. See http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs and http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools. It's not entirely straightforward, eg. Mozilla's own jemalloc isn't annotated properly (see bug 503249). > One thing to note: valgrind only runs on 10.5, not 10.4 or 10.6. > Unfortunately, this bug only seems to happen on 10.4, it almost never occurs on > 10.5. Go figure. There are no plans to make Valgrind work on 10.4, it seems highly unworthwhile given its finite lifetime. Making 10.6 work is a much higher priority. As for the flash+Valgrind crash, we may be able to do something if you can file a bug at https://bugs.kde.org/enter_valgrind_bug.cgi. Although it sounds like it probably won't help with this bug since it's mostly happening with 10.4.

Here are my steps for crashing 3.5.5 under 10.4.11: 1. Create a new profile 2. Select Firefox > Preferences, Main panel and change "When Firefox starts" to "Show my windows and tabs from last time" 3. Open up each of the links below in new tabs: http://people.mozilla.com/~jdaggett/memtesting/iteratebuildlogs.html#23456 http://people.mozilla.com/~jdaggett/memtesting/iteratelongtext.html#4512 http://people.mozilla.com/~jdaggett/memtesting/iterateblogs.html#5297 These will cycle through various pages, where the #xxxx parameter specifies the reload time in ms. 4. Open up tabs for sites using Flash video: http://www.nba.com/video/channels/top_plays/2009/12/02/20091202_plays_of_week.nba/?ls=iref:nbahpt2 http://video.nytimes.com/ http://news.bbc.co.uk/2/hi/programmes/hardtalk/8388903.stm 5. Wander through nytimes.com pages, clicking on Flash banner ads, click around on pages that open up 6. Return to video pages, view videos at full screen, pause, restart, etc. 7. When videos complete, click on other videos on the page Repeat steps 5-7 and I usually crash within 5-10 minutes. Not always the same place but every now and then in the KeyEquals location. Example crash reports: http://crash-stats.mozilla.com/report/index/bp-7fbcca0a-619a-44b4-bc2c-2eef12091202 http://crash-stats.mozilla.com/report/index/bp-9df66c08-e853-4c35-93b3-16d5b2091202 http://crash-stats.mozilla.com/report/index/bp-b7f0de32-a077-409a-a79e-9c8042091202 http://crash-stats.mozilla.com/report/index/bp-2d3c2c83-89fc-4b81-a4e6-13f822091202 I still have not been able to reproduce this on builds other than 3.5.5 on Mac OS X 10.4.11, but I'm going to take a stab at reproducing this on XP.

looking at a sample of data from 2009-12-01 it confirms your findings of crashes only on 10.4.11. and only with releases 3.5x and below. Windows NT5.1.2600 Service Pack 3 might be your best chance at reproducing on windows. checking --- 20091201-crashdata.csv nsRuleNode::Transition release total-crashes nsRuleNode::Transition crashes pct. all 230708 54 0.000234062 3.0.15 48996 32 0.000653115 3.5.5 120703 14 0.000115987 3.6b4 17457 0 3.6b3 2149 0 3.6b2 1187 0 3.6b1 2899 0 all releases 1 3.0 1 3.0.1 1 3.0.12 32 3.0.15 1 3.0.3 1 3.0.4 1 3.0.8 1 3.5 1 3.5.1 14 3.5.5 os breakdown 25 0.462963 Windows NT5.1.2600 Service Pack 3 17 0.314815 Windows NT5.1.2600 Service Pack 2 3 0.0555556 Mac OS X10.4.11 8S2167 2 0.037037 Windows NT6.0.6002 Service Pack 2 2 0.037037 Windows NT6.0.6001 Service Pack 1 1 0.0185185 Windows NT6.1.7600 1 0.0185185 Windows NT6.0.6000 1 0.0185185 Windows NT5.1.2600 Dodatek Service Pack 3 1 0.0185185 Windows NT5.1.2600 Dodatek Service Pack 2 1 0.0185185 Mac OS X10.4.11 8S165

When running Flash video on 10.5, valgrind spits out *zillions* of the error below: ==43165== Invalid read of size 4 ==43165== at 0x86B000: _pthread_mutex_init (in /usr/lib/libSystem.B.dylib) ==43165== by 0x382823E4: ??? (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x3829C0BB: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x3829C475: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x37FEB1D4: ??? (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x38149A8B: ??? (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x3834CB13: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x383300F9: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x38330597: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x38292047: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) ==43165== by 0x27DE7B0: nsNPAPIPluginInstance::InitializePlugin() (nsNPAPIPluginInstance.cpp:1190) ==43165== by 0x27E900B: nsPluginHost::TrySetUpPluginInstance(char const*, nsIURI*, nsIPluginInstanceOwner*) (nsPluginHost.cpp:3541) ==43165== Address 0x387260a4 is not stack'd, malloc'd or (recently) free'd ==43165== Output of 'sudo vmmap <pid>' just after valgrind outputted the error above: VM_ALLOCATE ? 36787000-36903000 [ 1520K] rwx/rwx SM=COW __DATA 37854000-379e4000 [ 1600K] rw-/rwx SM=COW ...onents.component/Contents/MacOS/QuickTimeComponents __DATA 379e4000-37a24000 [ 256K] rw-/rwx SM=PRV ...onents.component/Contents/MacOS/QuickTimeComponents __OBJC 37a24000-37a25000 [ 4K] rw-/rwx SM=COW ...onents.component/Contents/MacOS/QuickTimeComponents __IMPORT 37a25000-37a2a000 [ 20K] rwx/rwx SM=COW ...onents.component/Contents/MacOS/QuickTimeComponents VM_ALLOCATE ? 37ba5000-37fa5000 [ 4096K] rwx/rwx SM=PRV __DATA 385df000-38613000 [ 208K] rw-/rwx SM=COW ...Ins/Flash Player.plugin/Contents/MacOS/Flash Player __DATA 38613000-386ef000 [ 880K] rw-/rwx SM=PRV ...Ins/Flash Player.plugin/Contents/MacOS/Flash Player __OBJC 386ef000-386f0000 [ 4K] rw-/rwx SM=COW ...Ins/Flash Player.plugin/Contents/MacOS/Flash Player __IMPORT 386f0000-386f2000 [ 8K] rwx/rwx SM=COW ...Ins/Flash Player.plugin/Contents/MacOS/Flash Player VM_ALLOCATE ? 3871e000-3881e000 [ 1024K] rw-/rwx SM=PRV VM_ALLOCATE ? 39fdf000-3a3df000 [ 4096K] rwx/rwx SM=PRV mapped file 3a3df000-3aeec000 [ 11.1M] rw-/rwx SM=COW /Library/Fonts/ヒラギノ明朝 Pro W3.otf mapped file 3aeec000-3b982000 [ 10.6M] rw-/rwx SM=COW /Library/Fonts/ヒラギノ明朝 Pro W6.otf __DATA 64b07000-64b08000 [ 4K] rw-/rwx SM=COW ...sions/A/Frameworks/Print.framework/Versions/A/Print __IMPORT 64b08000-64b09000 [ 4K] rwx/rwx SM=COW ...sions/A/Frameworks/Print.framework/Versions/A/Print __DATA 8fe2e000-8fe30000 [ 8K] rw-/rwx SM=COW /usr/lib/dyld __DATA 8fe30000-8fe31000 [ 4K] rw-/rwx SM=ZER /usr/lib/dyld ==== Legend SM=sharing mode: COW=copy_on_write PRV=private NUL=empty ALI=aliased SHM=shared ZER=zero_filled S/A=shared_alias Note that the region valgrind is having a hissy fit about has definitely been allocated, it's not unmapped memory. Maybe some sort of shared memory buffer used by a GL library (wild-assed guess)? After spewing these errors for 10 minutes or so, valgrind just hangs. *sigh*

(In reply to comment #37) > When running Flash video on 10.5, valgrind spits out *zillions* of the error > below: > Run valgrind with --gen-suppressions to get a suppressions file for this, and maybe you'll get past it to other errors. See the manual for details.

(In reply to comment #37) > When running Flash video on 10.5, valgrind spits out *zillions* of the error > below: > [...] > Note that the region valgrind is having a hissy fit about has definitely been > allocated, it's not unmapped memory. Maybe some sort of shared memory buffer > used by a GL library (wild-assed guess)? This was fixed at ------------------------------------------------------------------------ r11031 | sewardj | 2010-01-27 11:28:00 +0100 (Wed, 27 Jan 2010) | 5 lines Fix handling of mprotect so as to be more consistent with the handling of mmap. Fixes #205541 and its dup #210268. The fix is simple enough but the analysis is a bit complex, as detailed in comments. > After spewing these errors for 10 minutes or so, valgrind just hangs. *sigh* I spent some time chasing this around (on 10.5.8) but was never able to figure out what was going on.

I looked at this more. I managed to run (1.9.2 + libflashplayer-10.0.45.2.linux-x86_64.so) on x86_64 Linux and this managed to play various clips successfully, at about 1 fps. I tried the same on MacOSX 10.5.8, 32-bit, 1.9.2. This was slower and less successful. The one possibly useful thing I discovered is that we appear to be passing uninitialised junk to flashplayer, somewhere, which probably isn't helping. This was reported on both Linux and MacOSX, but I think they are unrelated. The first such complaint, for MacOSX is below. We generate some uninitialised memory in nsChildViewConstructor(nsISupports*, nsID const&, void**) and that allegedly ends up being used to control a branch somewhere deep inside flashplayer. The same source apparently ends up getting used at another circa 50 locations. btw, ignore the "Flash_EnforceLocalSecurity" names. I suspect these merely reflect the fact that it was the nearest preceding symbol name to the given locations, and so is not to be relied on. Conditional jump or move depends on uninitialised value(s) at 0x6D3BCE9: SetOrigin (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD) by 0x23102330: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) by 0x23103C3E: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) by 0x23107282: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) by 0x23107D92: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) by 0x2305FF01: Flash_EnforceLocalSecurity (in /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player) by 0x269FC02: nsNPAPIPluginInstance::HandleEvent(nsPluginEvent*, int*) (nsNPAPIPluginInstance.cpp:1546) by 0x20591A6: nsPluginInstanceOwner::Notify(nsITimer*) (nsObjectFrame.cpp:5518) by 0x2857736: nsTimerImpl::Fire() (nsTimerImpl.cpp:430) by 0x2857896: nsTimerEvent::Run() (nsTimerImpl.cpp:519) by 0x2854979: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:527) by 0x28191B1: NS_ProcessPendingEvents_P(nsIThread*, unsigned int) (nsThreadUtils.cpp:200) by 0x27C4BEB: nsBaseAppShell::NativeEventCallback() (nsBaseAppShell.cpp:121) by 0x278EFF4: nsAppShell::ProcessGeckoEvents(void*) (nsAppShell.mm:506) by 0x5EC53C4: CFRunLoopRunSpecific (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) by 0x5EC5AA7: CFRunLoopRunInMode (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) by 0x4D292AB: RunCurrentEventLoopInMode (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4D28FFD: ReceiveNextEventCommon (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4D87B55: _AcquireNextEvent (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4DE1734: _TrackMouseLocationOrAreaReturningEvent (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4DE1487: TrackMouseLocationWithOptions (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4DE1234: HIView::BasicTrackInternal(CGPoint const&, unsigned long, short, void (*)(OpaqueControlRef*, short), unsigned char, GlyphState const*, unsigned long*) (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4DE0D90: HIView::TrackSelf(OpaqueEventRef*, short*) (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) by 0x4D0F84F: HIView::EventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) Uninitialised value was created by a heap allocation at 0x15AA9: operator new(unsigned long) (vg_replace_malloc.c:261) by 0x27B0EDD: nsChildViewConstructor(nsISupports*, nsID const&, void**) (nsWidgetFactory.mm:71) by 0x2819BCB: nsGenericFactory::CreateInstance(nsISupports*, nsID const&, void**) (nsGenericFactory.cpp:80) by 0x284EAAB: nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1597) by 0x2815A19: CallCreateInstance(nsID const&, nsISupports*, nsID const&, void**) (nsComponentManagerUtils.cpp:157) by 0x2815B25: nsCreateInstanceByCID::operator()(nsID const&, void**) const (nsComponentManagerUtils.cpp:199) by 0x281529A: nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (nsCOMPtr.cpp:150) by 0x205BAA2: nsObjectFrame::CreateWidget(int, int, int) (nsCOMPtr.h:707) by 0x205BCE2: nsPluginInstanceOwner::CreateWidget() (nsObjectFrame.cpp:5690) by 0x26B014E: nsPluginHost::InstantiateEmbeddedPlugin(char const*, nsIURI*, nsIPluginInstanceOwner*) (nsPluginHost.cpp:3265) by 0x20576A7: nsObjectFrame::InstantiatePlugin(nsIPluginHost*, char const*, nsIURI*) (nsObjectFrame.cpp:1012) by 0x205DD57: nsObjectFrame::Instantiate(char const*, nsIURI*) (nsObjectFrame.cpp:2084) by 0x21B95DD: nsObjectLoadingContent::Instantiate(nsIObjectFrame*, nsACString_internal const&, nsIURI*) (nsObjectLoadingContent.cpp:1770) by 0x21B9A52: nsObjectLoadingContent::EnsureInstantiation(nsIPluginInstance**) (nsObjectLoadingContent.cpp:791) by 0x23464D6: nsHTMLPluginObjElementSH::GetPluginInstanceIfSafe(nsIXPConnectWrappedNative*, JSObject*, nsIPluginInstance**) (nsDOMClassInfo.cpp:9436) by 0x2346851: nsHTMLPluginObjElementSH::SetupProtoChain(nsIXPConnectWrappedNative*, JSContext*, JSObject*) (nsDOMClassInfo.cpp:9516) by 0x23469FA: nsHTMLPluginObjElementSH::PostCreate(nsIXPConnectWrappedNative*, JSContext*, JSObject*) (nsDOMClassInfo.cpp:9629) by 0x1E34693: FinishCreate(XPCCallContext&, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, XPCWrappedNative*, XPCWrappedNative**) (xpcwrappednative.cpp:660) by 0x1E376A7: XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, nsWrapperCache*, int, XPCWrappedNative**) (xpcwrappednative.cpp:590) by 0x1E20729: XPCConvert::NativeInterface2JSObject(XPCLazyCallContext&, long*, nsIXPConnectJSObjectHolder**, nsISupports*, nsID const*, XPCNativeInterface**, nsWrapperCache*, JSObject*, int, int, unsigned int*) (xpcconvert.cpp:1199) by 0x1E4EFA4: xpc_qsXPCOMObjectToJsval(XPCLazyCallContext&, nsISupports*, nsWrapperCache*, nsID const*, XPCNativeInterface**, long*) (xpcquickstubs.cpp:1095) by 0x1E5A7CF: nsIDOMNode_GetFirstChild(JSContext*, JSObject*, long, long*) (dom_quickstubs.cpp:3815) by 0x1C6C36: js_NativeGet (jsscope.h:613) by 0x1C7490: js_GetPropertyHelper (jsobj.cpp:4277)

(In reply to comment #40) > we appear to be > passing uninitialised junk to flashplayer, somewhere, which probably > isn't helping. This was reported on both Linux and MacOSX, but I > think they are unrelated. Here's the x86_64 Linux complaint. Note, this is 1.9.2. With m-c I could not reproduce this, but that's not surprising, presumably because the environment in which the flashplayer is run is completely different, being out of process n'all. Conditional jump or move depends on uninitialised value(s) at 0x22204D09: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x222063DA: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x22206476: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x2220682B: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x22206CB2: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x222097A0: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21F7A81F: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21EA311D: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21DB2423: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21DB73FE: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21FA35C0: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) by 0x21EC251F: ??? (in /home/sewardj/.mozilla/plugins/libflashplayer.so) Uninitialised value was created by a heap allocation at 0x4C25D41: operator new(unsigned long) (vg_replace_malloc.c:261) by 0x5DC9724: PLUG_NewPluginNativeWindow(nsPluginNativeWindow**) (nsPluginNativeWindowGtk2.cpp:138) by 0x572947E: nsPluginInstanceOwner::nsPluginInstanceOwner() (nsObjectFrame.cpp:2502) by 0x572AD86: nsObjectFrame::PrepareInstanceOwner() (nsObjectFrame.cpp:2002) by 0x572C45C: nsObjectFrame::Instantiate(char const*, nsIURI*) (nsObjectFrame.cpp:2067) by 0x588FF88: nsObjectLoadingContent::Instantiate(nsIObjectFrame*, nsACString_internal const&, nsIURI*) (nsObjectLoadingContent.cpp:1770) by 0x589063C: nsAsyncInstantiateEvent::Run() (nsObjectLoadingContent.cpp:156) by 0x5FB272F: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:527) by 0x5F78BA6: NS_ProcessPendingEvents_P(nsIThread*, unsigned int) (nsThreadUtils.cpp:200) by 0x5EB995D: nsBaseAppShell::NativeEventCallback() (nsBaseAppShell.cpp:121) by 0x5EA23C1: nsAppShell::EventProcessorCallback(_GIOChannel*, GIOCondition, void*) (nsAppShell.cpp:70) by 0x97A2BCD: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2200.3

Can you tell the offset within the allocated block that the uninitialized value was at?

(In reply to comment #37) > After spewing these errors for 10 minutes or so, valgrind just > hangs. *sigh* www.ubergeek.tv shows a small flash video involving a red robot devil (no, don't ask). The video is small and simple enough that it runs on V on MacOSX without hanging. (In reply to comment #42) > Can you tell the offset within the allocated block that the > uninitialized value was at? Not directly. I can find out indirectly by initialising fields in turn and seeing if the complaints go away, but each trial takes ~15 cpu mins. Will try later today. In the meantime, I compared the definition and constructor for nsChildView, at widget/src/cocoa/nsChildView.h:282 and widget/src/cocoa/nsChildView.mm:496. It appears that the constructor does not initialise the following fields: mAccessible mTempThebesSurface mPluginPort mPluginInstanceOwner Is this intentional? Are they initialised somewhere else?

Josh should be able to answer that :-)

mAccessible and mTempThebesSurface don't need to be initialized - one is an nsCOMPtr and the other is an nsRefPtr. It is a bug that we're not initializing mPluginInstanceOwner to nsnull. I'll take care of this. The situation with mPluginPort is a little unclear but it looks like there may be a bug there.

I retested with the following patch, which initialised all 4 fields. It causes all the complaints described in comment #40 to disappear, which syncs with Josh's comments. Some numbers (to be taken with a pinch of salt): prior to this, Valgrind reported 54431 errors from 168 contexts to start up and run the red robot devil movie for a few minutes. A roughly comparable run with the patch produces 13558 errors from 103 contexts, a big drop. diff -r dca79ffca449 widget/src/cocoa/nsChildView.mm --- a/widget/src/cocoa/nsChildView.mm Mon Mar 15 12:31:49 2010 -0400 +++ b/widget/src/cocoa/nsChildView.mm Fri Mar 19 22:42:54 2010 +0100 @@ -497,11 +497,17 @@ , mView(nsnull) , mParentView(nsnull) , mParentWidget(nsnull) +#ifdef ACCESSIBILITY +, mAccessible(0) +#endif +, mTempThebesSurface(0) , mVisible(PR_FALSE) , mDrawing(PR_FALSE) , mLiveResizeInProgress(PR_FALSE) , mPluginDrawing(PR_FALSE) , mPluginIsCG(PR_FALSE) +, mPluginPort() +, mPluginInstanceOwner(0) { #ifdef PR_LOGGING if (!sCocoaLog) {

Josh, I saw your patch for mPluginInstanceOwner, but what's the story for mPluginPort?

Minimal, re-verified patch that initialises just mPlugin{Port,InstanceOwner}.

Josh submitted a patch for mPluginInstanceOwner in bug 553702.

(In reply to comment #47) > Josh, I saw your patch for mPluginInstanceOwner, but what's the story for > mPluginPort? It's on my list. Not quite as trivial to fix as mPluginInstanceOwner.

(In reply to comment #49) > Josh submitted a patch for mPluginInstanceOwner in bug 553702. Even with this in place, most of the complaints listed in comment #40 are still there. I guess mPluginPort needs fixing too.

I've been seeing a crash with this signature for week or so. e.g. http://crash-stats.mozilla.com/report/index/56422440-9135-41f2-bc12-ced052100321 I figured the start of the crashing coincided with my changing the font properties. Now I have a fairly reproducible way to crash. The key seems to be to use the Antique Olive Roman AOR font. I like the font but it has caused problems before like after the change to cairo. I believe I got the font with Photoshop 7 years ago. I was crashing often with my daily profile but it took me a while to get something in a clean profile. 1a. In the font dialog change the proportional font from using serif to san serif. 1b. Change the default san serif font to AOR. 1c. Uncheck the box to that allows pages to choose their own font. 2. Goto this page: http://www.rotoworld.com/content/playernews.aspx?sport=NHL&line=106324 This won't crash there. But browsing in other tabs then changing back to that tab may crash. Also sometimes scrolling the page crashes too. The page zoom may also be a factor. At some zoom levels some of the words are not drawn. I have not noticed that happening before with previous incidences of these crashes. I've only seen that on this page so I'm not sure of the relevance of that. And flash is not involved here since I have it disabled in my daily use profile. And the crash occurs in a clean profile with flash disabled too.

Brian, can you file a new bug for that? If the problem where the words are not drawn is more easily reproducible, that would be a good way to attack it.

Brian, it would be fantastic to be able to reproduce this crash. As roc suggests, could you open a new bug? This bug is logged against Mac OSX but your crash report looks like a Windows crash. It might be the same bug but it would be a good idea to try and reproduce your testcase in a separate bug. It would be really helpful to know the exact version of Antique Olive Std you have (Type1? OTF? which version?). Font Folio 11 has the .otf version, v.2.0.35. The Microsoft font properties extension will let you view exact version information for fonts, install it and then look at the properties of a given font, various tabs contain all sorts of info on the font. Also, when you browse around other tabs is there anything specifically you browse to?

Filed bug 555018 about initializing Mac OS X plugin ports.

(In reply to comment #54) > Brian, it would be fantastic to be able to reproduce this crash. As roc > suggests, could you open a new bug? FTR, this was filed as bug 553963.

All Firefox crash reports in the past 4 weeks appear on 3.0 and 3.6. Showing in Thunderbird 3.1 only. Resolving as works for me.

Issue is resolved - clearing old keywords - qa-wanted clean-up