Closed Bug 118014 Opened 23 years ago Closed 23 years ago

Trunk M099 crashes [@ FrameManager::ReResolveStyleContext] [@ RuleProcessorData::RuleProcessorData][@ nsXULElement::GetID]

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P2)

x86
All
defect

Tracking

()

CLOSED FIXED
mozilla1.0

People

(Reporter: greer, Assigned: joki)

References

Details

(4 keywords, Whiteboard: [adt1] [ETA 04/15] [m5+][hitlist] [FIXED_ON_TRUNK])

Crash Data

Attachments

(8 files, 5 obsolete files)

14.04 KB, text/plain
Details
17.60 KB, text/plain
Details
10.92 KB, text/plain
Details
10.92 KB, text/plain
Details
17.52 KB, application/x-javascript
Details
1.28 KB, patch
dbaron
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
30 bytes, text/css
Details
533 bytes, text/html
Details
The Trunk has shown crashes at RuleProcessorData::RuleProcessorData since the 2001122311 build. I haven't been able to crash with the given URLs on a Win2000 using the 20010103 build. RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp line 3264] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp line 1076] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 971] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1837] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1914] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1914] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 2175] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5408] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5426] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp line 1419] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 1197] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 900] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 955] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 991] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 751] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp line 145] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp line 2388] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1072] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp line 303] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1280] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1597] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1615] WinMainCRTStartup() KERNEL32.DLL + 0x7903 (0x77e87903) Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/style/src/nsCSS StyleSheet.cpp line : 3264 (1153541) URL: https://moja.tatrabanka.sk (1130738) URL: https://my.iplanet-cert-server.com:8100 (1130738) Comments: Hit back several time in a row and pow! I was hitting my local Apache on a SuSE Linux box but I don't think that matters. I heard a lot of disk access as it crashed. (1061747) URL: news.bbc.co.uk/sport/hi/english/football/default.stm (1061747) Comments: clicked lick. moz died. I've used the bbc pages many times with moz and never had a problem before.
Adding keywords, including qawanted to see if we can get someone who can repro this.
Keywords: crash, qawanted, topcrash
Could you attach the disassembly, registers, and stack for a single talkback report (along with the build date for that report)?
Presumably the content node (aContent) is either an invalid or dangling pointer.
Oh, interesting, the content node that's the problem is coming out of the undisplayed content map (nsFrameManager.cpp line 1837).
dbaron, here's an attachment with the registers, stack dump and the regular stack from incident 1213768, build 2002010310. Let me know if you need anything else.
Thanks. That shows that the content pointer is pointing to valid memory, but that that memory contains either garbage (i.e., the pointer is just something else) or a deleted object (more likely).
Any ideas why we'd be failing to clear the undisplayed content nodes? Do we have ways that remove content that don't go through the right codepaths in nsCSSFrameConstructor? I guess the fact that we have these notifications spread over 5 places seems a bit fragile.
Couldn't any nsIContent call (AppendChild, InsertChild, ...) that fails to |aNotify| be suspect?
It looks like this crash started in the morning builds on 2001-12-19.
*** Bug 119170 has been marked as a duplicate of this bug. ***
->Layout, since this seems like some sort of garbage coming out of the undisplayed content map, and I'm not going to have the time to look at it.
Assignee: dbaron → attinasi
Component: Style System → Layout
QA Contact: ian → petersen
MailNews crashes consistently for me at RuleProcessorData::RuleProcessorData when I press "n" to go to the next unread message and click "OK" when MailNews asks if I want to advance to the next unread message in another folder. Advancing to the next unread message in a newsgroup does not have the same effect, and the crash isn't always in RuleProcessorData::RuleProcessorData, but it usually is (as you can see by querying the talkback reports for myk@mozilla.org).
*** Bug 121103 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla0.9.9
*** Bug 122276 has been marked as a duplicate of this bug. ***
*** Bug 119375 has been marked as a duplicate of this bug. ***
Any progress on this one? This is a major topcrasher on the MozillaTrunk and will likely be a major issue with Mozilla 0.9.8 as well! Here's the latest from Talkback: Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/style/src/nsCSSStyleSheet.cpp line : 3264 (2504139) Comments: I loaded MailNews (2474337) Comments: clicked on the back button twice (2474126) Comments: another back click crash. (2435817) Comments: clicked back. crash. (2427569) Comments: Clicked three times quickly on "back button" while reading a talkback thread on Mozillazine. (2403930) URL: www.w3c.org (2403930) Comments: viewing the validation of one of my pages. Clicked back. Boom. (2387874) Comments: sorry for saying f**k you before... <--------THIS IS FUNNY! (i censored it just to be safe) (2387330) Comments: f**k you! (2312088) URL: www.emol.com (2312088) Comments: I just opened the web page! (2295941) URL: https://helpdesk.princeton.edu/opm (2289858) URL: telmore.dk (2289858) Comments: dealing with a big PDF file with Acrobat plugin (2245265) Comments: Pondering bugzilla (2203297) URL: http://forum.uniba.sk (2203297) Comments: click on the Help forum link (2180721) URL: www.news.com (2180721) Comments: Go to article about amazon making a profit. Go back. (2163968) URL: http://home.netscape.com (2136905) Comments: Hit link at SuSe linux site (2109917) Comments: Crash when loading MailNews The stack is the same as originally reported, and a lot of the comments still mention clicking the back button.
Marking nsbeta1+
Keywords: nsbeta1+
*** Bug 125032 has been marked as a duplicate of this bug. ***
*** Bug 125752 has been marked as a duplicate of this bug. ***
*** Bug 125579 has been marked as a duplicate of this bug. ***
updating summary with M098, since this is a topcrasher with Mozilla 0.9.8: RuleProcessorData::RuleProcessorData 324 118014 NEW attinasi@netscape.com mozilla0.9.9 Tue 11:01 BBID range: 2518602 - 2935976 Min/Max Seconds since last crash: 4 - 624484 Min/Max Runtime: 4 - 1432509 Crash data range: 2002-02-04 to 2002-02-14 Build ID range: 2002020409 to 2002020415 Keyword List : button(10), download(4), load(8), mail(15), start(8), browser(6), back(19), Stack Trace: RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp line 3264] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp line 1073] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 971] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1855] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1932] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1932] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 2193] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5341] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5359] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp line 1419] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 1197] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 900] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 955] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 991] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 751] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp line 163] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp line 614] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1072] KERNEL32.DLL + 0x24407 (0xbff94407) 0x00648c16 Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/style/src/nsCSSStyleSheet.cpp line : 3264 (2919768) URL: www.motorola.pl (2919768) Comments: I'm not sure ... but I think I was click back once time too much and ... crash (2915302) Comments: Playing with back/forward buttons (2906394) Comments: selecting messages in mail .holding ctrl and ckicking on messages (2905880) URL: http://www.gitsecurity.com/ (2905880) Comments: Was hitting the back button after viewing most of the pages in the 7100 starter. (2898593) URL: http://www.spielanleitung.com (2897785) URL: http://www.tilt.tv/ (2897775) URL: http://www.tilt.tv/ (2897698) Comments: pressing 'N' to get to my second mailbox which had two new msgs in it- it just bombed before showing any of them (2894784) URL: www.benchmark.pl (2893349) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2883561) URL: www.rhinosoft.com (2883561) Comments: I am steping back from other pages (www.download.com) to this site. (2874435) URL: http://www.oktax.state.ok.us/ (2873357) URL: http://www.register.com/url-jump.cgi (2871958) URL: http://my.yahoo.com (2871958) Comments: clicked the back button a bunch of times faster than the browser could go back. (2868741) Comments: Hi there I had many tabs in one window (around eight) and had just control clicked on a link to Microsoft's SNMP advisory from CERT's SNMP advisory. Hope this helps. (2862153) URL: www.mozilla.org (2861993) URL: www.mozilla.org (2860804) Comments: new mail - went from one mail folder with no new mail to another folder with new mail - tried to display it but crashed instead (2859165) URL: cbs.com (2853487) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2848285) Comments: just resized window in winxp (2836456) URL: http://www.ricardo.de (2836234) URL: www.mozilla.org (2833649) Comments: I was using mozilla to do a web preview of a presentation created by Microsoft Powerpoint XP. I did File->Web Page Preview clicked through a couple of pages and Mozilla crashed. (2831494) URL: www.vbextras.com (2831106) URL: www.microsoft.com (2829126) URL: www.microsoft.com (2827980) URL: http://www.tilt.tv/ (2825486) URL: cbs.com (2820516) URL: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-005.asp (2817656) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2815209) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2812224) Comments: load a new page when the previous one was stillloading (2810968) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2810968) Comments: Sending a form (2810912) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2810856) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2808614) Comments: When I opened a page and tried to go back to the previous page using right click and "Back" Mozilla crushed. (2807572) Comments: launcing mail (2797038) URL: www.microsoft.com (2797038) Comments: Just browsing around (2796709) URL: http://www.surfmy.net/cgi-bin/sqwebmail (2782857) URL: http://www.suntimes.com/weather/stateradar.html (2773314) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2772560) URL: http://www.nouvelobs.fr/index2.html (2772560) Comments: launch e-mail client (2771162) Comments: ??? presed back twice... (2769608) URL: www.gnome.org (2769608) Comments: clicked back button (2769165) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2766021) Comments: Just load a new page ()!*@)(!! (2761077) URL: http://www.w3c.org/TR/html401/struct/lists.html (2761077) Comments: I impatiently clicked the "back" button repeatedly in the browser. (2757009) URL: someplace on alprosoja.com (2757009) Comments: clicking back button (2742794) Comments: I was going back in page history with mouse wheel. (2735359) URL: www.eclipse.org (2735359) Comments: Clicked on the small "home" text (top left) from one of the other pages (2727486) URL: http://www.keswickplus.co.uk/pics/townmap.gif (2723928) Comments: opened browser (2717183) URL: www.nickels.de (2695478) URL: http://www.cnn (2695478) Comments: At the moment of failure I was pressing 'back' button several times to get to the home page (2690377) Comments: Dragged e-mail address in AddressBook from Collectedto Personal then resized thw AddressBook window. (2687193) URL: www.wellsfargo.com (2687193) Comments: I rejected the setting of a third cookie from their login activation page when the crash occurred. (2682573) Comments: starting mail client and itwas downloading new mesgs (2675060) Comments: Pressed backspace multiple times after browsing several pages. (2671450) Comments: Next New Mail (2669494) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2669470) URL: http://www.mbnet.fi/hintaseuranta/esittelyt/digikamera.asp (2669431) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2669411) URL: http://www.mbnet.fi/hintaseuranta/etusivu.asp (2664153) Comments: using bookmark utility to open a site (2662684) URL: http://netgroup-serv.polito.it/winpcap/misc/links.htm (2662684) Comments: i change the font from 100% to 150% then go to the http://netgroup-serv.polito.it/winpcap/misc/links.htmthen mozilla crash (2659569) Comments: Paging back from looking at mrtg graphs. This has worked fine before. (2652627) URL: http://www.google.com/url?q=http://www.princetonreview.com/trace/trace.asp%3FadCode%3D6489%26entryURL%3Dhttp://www.princetonreview.com/testprep/gmat.asp&sa=A&ai=dlhohx:a:edxnf:bsqyy:pov:fyh:nhwwx:dx:dhhazzs:cdmkg:lihlkc:bssq:ohlmq (2652627) Comments: I did a Google search for Kaplan GMAT and then I clicked on thePrinceton Review sponsored Link (2649928) URL: www.dayofdefeatmod.com (2649928) Comments: trying to start a file download (2645685) URL: I don't know... :) sorry (2645472) Comments: Starting up mail (imap over ssl) (2643263) Comments: installed Windows Media Player Plug-in (2638752) Comments: Scrolling down the mail message side pannel while a delete of the last read IMAP message in my inbox was in progress. (2628156) URL: www.ivl.se (2624390) URL: http://www.iht.com/frontpage.html (2624390) Comments: fast double-click on the forward-button (to go back to the top of the list which was 2 places away) (2617852) URL: http://www.fleetstreetclinic.com/dvt/ (2617852) Comments: site loaded. click on link before load completed - caused crashsite contains no javascript. only plain html + css (2615083) URL: http://www.goli.at/phil/mozilla/bugs2.html (2615083) Comments: Finished reading mails in my inbox (2613554) URL: http://java.nikkeibp.co.jp/Java/AC/N2002/0131colum.html (2613554) Comments: The page has a hyperlink which has attribute 'target="_new"'.I did want to let mozilla open new Tab instead of opening new WIndowwith such attribute check that preference in Preferences. Then clickedthe link still new window was opened. This seemed (2613554) Comments: weird to me thenI restarted mozilla and did it again then this time mozilla crashed.My mozilla revision is 0.9.8 running on RH7.2 (which has been upgradedfrom RH7.1 with RH7.2 ftp-version installer) with Ximian GNOME.I installed mozilla into (2613554) Comments: /usr/lib/mozilla with full installer *-sea.tar.gz archive.Hope this helps (2611231) Comments: deleting mail from my inbox (2607938) Comments: Just only open the email (2605282) URL: cbs.com (2605282) Comments: doubletree.comchoose portland and oregonclick on lloydcenter and crash (2605155) URL: cbs.com (2605155) Comments: clicked a link (2599271) Comments: messenger startup (2586191) Comments: I was doing a "back" function... to attempt to return to the previous page. I hit "back" several times in quick succession and got the error. (2581515) URL: www.web.de (2579647) URL: www.borland.com/support/newsgroups (2579647) Comments: subscribing to a borland newsgroup from website. Crash occured during the switch between browser and newsreader. (2577176) URL: http://www.nkss.no/ost/ (2577176) Comments: clicked on a link...a picture came up and the browser go down... (2572821) Comments: Apparently two Links clicked to fast one after another (2571974) Comments: I was using Alt-MouseWheel to scroll back & forth thru the browser windowshistory. (2559076) Comments: started up in mail crashes every time - to avoid I need to start up with -ProfileManager!!!!! (2546503) URL: I'm not sure... the first page it tries to load after an install... it never got far enough to see (2546503) Comments: Loading for the first time after install... It got as far as starting up attempting to load the first page then boom. (2544464) URL: www.necn.com (2544464) Comments: just typed in URL & it crashed (2540048) URL: www.palmos.com (2540048) Comments: Hitting the backbutton (2537175) URL: http://www.gimp-online.de (2537137) URL: http://www.gimp-online.de (2535083) Comments: pressing the back button (2531728) Comments: Tried to download jre plugin cancled it went to another page then closed mozilla. (2531364) Comments: attempted (again) to access perl documentation on local machine port 81 (http://localhost:81/perl/) (2531361) Comments: attempted to access top level of perl documentation (2525871) Comments: Open new mail !!!! (2521757) Comments: run it for the first time That's all the data we have for M098 right now, so hopefully we can get a reproducible testcase from all those user comments and urls. The target milestone is set to Mozilla 0.9.9...are we anywhere close to getting this fixed for that milestone?
Summary: Trunk crashes [@ RuleProcessorData::RuleProcessorData] → Trunk M098 crashes [@ RuleProcessorData::RuleProcessorData]
>The target milestone is set to Mozilla 0.9.9...are we anywhere close to getting >this fixed for that milestone? Sadly, no. I cannot reproduce it yet...
Status: NEW → ASSIGNED
I have attached more M098 data divided up by unique stack traces and their respective crash data. If QA could go through and try to reproduce this crash using the comments and urls that would be great! I have tried and have been unsuccessful...but this is a topcrasher...so we need a testcase!
Assignee: attinasi → attinasi_layout
Status: ASSIGNED → NEW
rolling forward to 1.0
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: mozilla0.9.9 → mozilla1.0
I have a reproducable crash from one of the links posted in this report: http://www.nkss.no/ost/ 1) Go to http://www.nkss.no/ost/ 2) Click on the link "forsiden" 3) Crash occurs. Tested under the Feb 27th OS X build (2002-02-07-08).
Stack trace on Feb 27th build (OS X) ********** Date/Time: 2002-02-27 15:40:49 -0800 OS Version: 10.1.3 (Build 5Q45) Host: localhost Command: Mozilla PID: 523 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000025 Thread 0 Crashed: #0 0x01f9c23c in _ct__17RuleProcessorDataFP14nsIPresContextP10nsIContentP12nsR #1 0x01f9c5c0 in RuleProcessorData::_dt(void) #2 0x01f37b9c in StyleSetImpl::ResolveStyleFor(nsIPresContext *, nsIContent *) #3 0x0295a588 in ResolveStyleContextFor__13nsPresContextFP10nsIContentP15nsISty #4 0x02a8e920 in ReResolveStyleContext__12FrameManagerFP14nsIPresContextP8nsIFr #5 0x02a8eb64 in ReResolveStyleContext__12FrameManagerFP14nsIPresContextP8nsIFr #6 0x02a8eb64 in ReResolveStyleContext__12FrameManagerFP14nsIPresContextP8nsIFr #7 0x02a8eda0 in ComputeStyleChangeFor__12FrameManagerFP14nsIPresContextP8nsIFr #8 0x0296d5f4 in PresShell::ReconstructStyleData(int) #9 0x0296d7ac in PresShell::StyleSheetAdded(nsIDocument *, nsIStyleSheet *) #10 0x01f298f0 in nsDocument::InsertStyleSheetAt(nsIStyleSheet *, int, int) #11 0x02105004 in InsertSheetInDoc__13CSSLoaderImplFP16nsICSSStyleSheetiP10nsICo #12 0x02103dd0 in SheetComplete__13CSSLoaderImplFP16nsICSSStyleSheetP13SheetLoad #13 0x02104170 in ParseSheet__13CSSLoaderImplFP21nsIUnicharInputStreamP13SheetLo #14 0x021043a4 in DidLoadStyle__13CSSLoaderImplFP15nsIStreamLoaderP8nsStringP13S #15 0x02103444 in OnStreamComplete__13SheetLoadDataFP15nsIStreamLoaderP11nsISupp #16 0x01ba0e38 in nsStreamLoader::OnStopRequest(nsIRequest *, nsISupports *, unsigned int) #17 0x01bf24f4 in nsHttpChannel::OnStopRequest(nsIRequest *, nsISupports *, unsigned int) #18 0x01be4770 in nsOnStopRequestEvent::HandleEvent(void) #19 0x01be3b80 in nsARequestObserverEvent::HandlePLEvent(PLEvent *) #20 0x005f4670 in PL_HandleEvent #21 0x005f44dc in PL_ProcessPendingEvents #22 0x0059a36c in nsEventQueueImpl::ProcessPendingEvents(void) #23 0x02485acc in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void) #24 0x02485890 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &) #25 0x011d1b14 in Repeater::DoRepeaters(EventRecord const &) #26 0x024999e8 in nsMacMessagePump::DispatchEvent(int, EventRecord *) #27 0x024995c0 in nsMacMessagePump::DoMessagePump(void) #28 0x02498f3c in nsAppShell::Run(void) #29 0x0244ddfc in nsAppShellService::Run(void) #30 0x004cbba4 in main1(int, char **, nsISupports *) #31 0x004cc67c in main Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x70283ea4 in TSWaitOnConditionTimedRelative #3 0x7027d748 in TSWaitOnSemaphoreCommon #4 0x702c2078 in TimerThread #5 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x01f9c23c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x20000018 lr: 0x01f9c1f4 ctr: 0x02959a80 mq: 0x00000000 r0: 0x00000001 r1: 0xbfffe740 r2: 0x02309000 r3: 0x045b5de0 r4: 0xbfffe7fc r5: 0x045b5de0 r6: 0x046e5200 r7: 0x00000000 r8: 0x02392c84 r9: 0x00000024 r10: 0x00000001 r11: 0x08159b5a r12: 0x00000001 r13: 0x037bf630 r14: 0x0469c2b4 r15: 0xbfffefc0 r16: 0x0452d5a4 r17: 0x02be26bc r18: 0x04400020 r19: 0xbfffe99c r20: 0x00000000 r21: 0x048d7e70 r22: 0xffffffff r23: 0xbfffeb8c r24: 0x00000000 r25: 0x048d6ed0 r26: 0x0451acf0 r27: 0x048d6ed0 r28: 0x045b5de0 r29: 0x0469c2b4 r30: 0xbfffe7cc r31: 0x045b5de0 **********
Keywords: testcase
I was just able to reproduce this also on my WinNT with build 2002022703. Here's what I did: 1. I had a few tabs open, went to http://www.nkss.no/ost/ and tried clicking on the first link...no crash. 2. Clicked on a few more links and no crash. 3. Clicked the back button a few times (probably 4 or 5) rapidly and boom! Here's my incident: Incident ID 3488057 Stack Signature RuleProcessorData::RuleProcessorData ae94021f Trigger Time 2002-02-28 13:36:51 Email Address jpatel@netscape.com URL visited http://www.nkss.no/ost/ Build ID 2002022709 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments just clicked on a few links on the site...and then clicked back a few times...and boom! was trying to repro bug 118014 Stack Trace RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp, line 3263] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1073] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 975] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1855] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1932] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1932] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 2193] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5344] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5362] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1438] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1197] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 900] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 955] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 991] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 751] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2504] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072]
jpatel/petersen, can either of you still reproduce this one? I haven't been able to crash with 2002030606 or M098 on Win2K. If we can consistently reproduce this one, please mark it as topcrash+. If not, we may need to remove the testcase KW.
Since updating to build 2002030608 I have not been able to reproduce the bug using my test case described in http://bugzilla.mozilla.org/show_bug.cgi?id=125579. Knock on wood... Carsten
What is our latest talkback on this bug? Can we close it as fixed or WFM?
Is TB3766051G this bug? If so, I can still reproduce this on build 2002-03-06-04 using the steps from bug 122276.
Marc, this one has 200+ crashes on M098 and 65 on the Trunk currently. I don't think we should close it as WFM ;-)
Marc, this one has 200+ crashes on M098 and 65 on the Trunk currently. I don't think we should close it as WFM ;-) There are however, a lot of detailed user comments that might help us track down a repro case. I'm attaching all of the comments here.
Jonas' crash in comment #83 is the same. Here are the steps from the bug he mentions: (On Win2000) Select a mail folder which has no unread messages in it. You must have at least one unread message in another folder. Press the space bar. You'll get an "Advance to next unread message in [folder]?" dialog. Press the space bar to select yes, and *before the view changes to the unread message in the folder*, quickly press the space bar again a couple of times. Crash.
There also seems to be 2 types of crashes being reported under this stack signature. The stack looks similar, but the steps to reproduce are different. A lot of people are crashing at different websites, but a few users are also consistantly crash launching mail/news.
If we are still getting thsi on the trunk, then by all means, leave it open, that is why I asked how recently we have seen it :) I cannot reproduce the crash in mail using the steps described. I have tried with a current CVS build, and I get some assertions but no crashes. I wonder if the mailbox has to have a certain number of messages, or some specific types of messages, or some specific sorting arrangement... I have tried threaded, sorted by date and subject, many many times, no crashes. Clearing testcase keyword - I am still not able to get anywhere with this one because I cannot reproduce it :( Believe me, I know it is nasty, and I want to fix it, but so far I cannot make it happen.
Keywords: testcase
Priority: P1 → P2
I contacted Alex "Rembrandt" Bischøff since a lot of the recent crashes on the Trunk were reported by him and although he too was unable to reproduce this crash for a few days...it's back for him. Here's what he said in his email: Hey Jay, Guess what? Bug 118014 is back :*-(. Talkback ID 3802770H. As usual, steps to reproduce: 1. Download latest nightly 2. Delete <moz-dir>/bin 3. Unzip nightly 4. Run Mozilla, run MailNews 5. Crash :(. My prefs.js is attached, if that helps. I will attach his pref.js in case it can provide us with any info.
I took a look at Alex's most recent crash, and the stack is different...so I'm not sure what's going on there. Here is the incident: Incident ID 3802770 Stack Signature 0x0401284e 5b939989 Trigger Time 2002-03-08 10:16:47 Email Address alex@spamcop.net URL visited Build ID 2002030805 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments Hey, it looks like bug 118014 is back. I'll be sure to e-mail Jay Patel about this. As usual, steps to reproduce: 1. Download latest nightly 2. Delete <moz-dir>/bin 3. Unzip nightly 4. Start Mozilla, start MailNews 5. Mozilla crashes Stack Trace 0x0401284e StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1080] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 975] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1855] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1932] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1932] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 2193] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5346] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5364] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1438] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1186] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 889] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 944] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 980] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 740] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2544] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1366] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1701] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1719] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08) That might be a different bug...and if it is, we can log a new bug on it. But maybe there are some clues in the stack since Alex used the same steps to reproduce it.
All these stacks seem related to a stylesheet *loaded via HTTP* that comes in *after* the page has already been displayed. I'm really having trouble thinking what such a thing would have to do with mailnews. The Mozilla mailnews start page is http://www.mozilla.org/mailnews/start.html , which has no linked stylesheets.
I read through code to look for places where the undisplayed map might be maintained incorrectly. Here are some things I found: nsCSSFrameConstructor::WipeContainingBlock doesn't call ClearAllUndisplayedContentIn on |aFrame|'s content. RemoveDummyFrameFromSelect, RemoveFloatingFirstLetterFrames, RemoveFirstLetterFrames, RecoverLetterFrames, and RemoveFixedItems (all methods of nsCSSFrameConstructor) don't call DeletingFrameSubtree but instead call RemoveFrame themselves. Could something could be happening with generated content, images, and 'display: none'? We do weird things like creating a content node for the image, don't we? nsCSSFrameConstructor::RemoveMappingsForFrameSubtree not called by somebody (anybody, anywhere) when destroying a frame?
David: In response to comment #42, I don't have the default homepage set for MailNews. Rather, I've configured this url instead: http://www.mozilla.org/quality/mailnews.html (as mentioned in my prefs.js, attachment 73251 [details]) Needless to say, that page /does/ have linked stylesheets.
One interesting note: for the builds when bug 129827 existed, this stack signature didn't show up in talkback at all.
The patch in bug 114234 could also fix the problem here.
... which reminds me -- I should also check callers of |ReplaceFrame|.
This also calls DeletingFrameSubtree in the two parts of CantRenderReplacedElement, where ReplaceFrame is used.
Attachment #73464 - Attachment is obsolete: true
Summary: Trunk M098 crashes [@ RuleProcessorData::RuleProcessorData] → Trunk M099 crashes [@ RuleProcessorData::RuleProcessorData]
Comment on attachment 73740 [details] [diff] [review] cover the ReplaceFrame callers too sr=attinasi
Attachment #73740 - Flags: superreview+
Taking bug (in the hopes that that patch will fix it, anyway).
Assignee: attinasi_layout → dbaron
Status: ASSIGNED → NEW
There is one typo in the patch where |aState.mFrameManager| should be |state.mFrameManager|.
I tested first-letter changes with the testcases in bugs 103248 and 23604. I tested CantRenderReplacedElement using testcases at: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html and I didn't see any crashes. So I think these changes are pretty safe, and I'm not going to try to come up with testcases for some of the more obscure instances that I changed, since all the changes are pretty much the same...
Comment on attachment 73740 [details] [diff] [review] cover the ReplaceFrame callers too r=kin@netscape.com
Attachment #73740 - Flags: review+
Comment on attachment 73740 [details] [diff] [review] cover the ReplaceFrame callers too a=brendan@mozilla.org for 1.0. /be
Attachment #73740 - Flags: approval+
Attachment 73740 [details] [diff] checked in. I'll wait for talkback data before deciding whether to mark the bug fixed.
*** Bug 130720 has been marked as a duplicate of this bug. ***
Well, this isn't fixed, although the numbers of crashes look like they might be reduced. However, there's a clear stack from the 14th (talkback 4058156) showing the problem.
*** Bug 131396 has been marked as a duplicate of this bug. ***
*** Bug 130629 has been marked as a duplicate of this bug. ***
Still crashing on M099 Here are the Incident IDs, build numbers, and any URLs or Comments for crashes dating from the 14th through the 17th. 4170018 2002031711 starting mozilla mail 4168289 2002031711 4132539 2002031621 4166531 2002031611 4164779 2002031611 4164135 2002031611 4144350 2002031611 www.tficomputer.it 4140694 2002031611 http://www.liberation.fr/quotidien/semaine/020311-030021072SOCI.html l aunch e-mail client 4138696 2002031611 http://www.photond.com/photond.htm Viewing next unread message in a inbox folder 4133372 2002031611 4120750 2002031611 4119233 2002031521 test case for www.dube.com click on javascript link (bugreport filed) 4119173 2002031521 www.dube.com click on javascript link (bugreport filed in) 4115090 2002031510 www.tficomputer.it 4110470 2002031510 4159292 2002031508 napaonline.com browsing above page. 4181638 2002031505 reading IMAP messages while FTP downloading 4145160 2002031505 4142872 2002031505 www.iamnotageek.com Pressed backpage 3 or 4 time very rapidly. 4104801 2002031505 4083116 2002031505
I think Marc pointed out the real problem here in bug 129350 comment 22 -- ReResolveStyleContext needs to update the style context in the undisplayed content map.
We could apply that part of the patch from bug 129350 that fixes the undisplayed node's style context. Then again, I'm hoping to get that whole patch in soon unless somebody comes up with a better fix in the next day or so. But either way, the undisplayed node's style context needs to be updated correctly.
Talkback seems to be reporting this same crash under a different stack signature: nsXULElement::GetID 13 BBID range: 4068484 - 4422941 Min/Max Seconds since last crash: 15 - 55928 Min/Max Runtime: 15 - 55928 Crash data range: 2002-03-15 to 2002-03-24 Build ID range: 2002031411 to 2002032211 Keyword List : Stack Trace: nsXULElement::GetID [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp line 3802] RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp line 3300] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp line 1080] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 975] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1773] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1850] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1850] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1897] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5378] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5402] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp line 1447] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 1185] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 888] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 943] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 979] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 739] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp line 2607] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1072] KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00648c16 Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xul/content/src/nsXULElement.cpp line : 3802 (4393975) URL: Yet another back crash. (4393975) Comments: . . . these are less common nowadays but they still happen. (4379911) URL: www.tficomputer.it (4308698) Comments: I was on sjmercury.com....I read 1-2 articles and then hit BACK...BOOM (4212009) URL: www.numasters.com (4212009) Comments: Moz crashes when forward button is clicked in rapid sucession and their are no more pages in the 'forward' buffer (same problem with the back button). Is there an entry in Bugzilla? If not I'll post one. (4208727) URL: http://www.liberation.fr/quotidien/semaine/020311-030021072SOCI.html (4208727) Comments: launch e-mail client and mozilla (4185407) URL: www.sony.com (4185407) Comments: clicking on back button (4178047) URL: http://www.dube.com (4178047) Comments: Bug 131396. Clicking on javascript:void(0) link. Crash when dismissing alert. (4128815) URL: http://www.target.com.au (4128815) Comments: looking up a store location second time today Mozilla has crashed doing the same task. (4128679) URL: http://www.target.com.au (4128679) Comments: looking up a store location this is not the first time it has happened while performing the same task. (4068484) URL: http://www.photond.com/photond.htm
Summary: Trunk M099 crashes [@ RuleProcessorData::RuleProcessorData] → Trunk M099 crashes [@ RuleProcessorData::RuleProcessorData][@ nsXULElement::GetID]
Adding testcase keyword and making topcrash+. I have been able to easily reproduce this crash at http://www.dube.com . I simply went to the site and clicked on the online catalog link at the bottom of the page. After clicking the link, I see javascript:void(0) in the status bar...and boom! Here is one of my incidents (WinNT with MozillaTrunk build 2002032503): Incident ID 4472198 Stack Signature RuleProcessorData::RuleProcessorData ae94021f Trigger Time 2002-03-25 18:34:16 Email Address jpatel@netscape.com URL visited http://www.dube.com Build ID 2002032510 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments just clicked on online catalog at bottom of page Stack Trace RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp, line 3280] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1080] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 975] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1773] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1850] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1850] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1897] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5378] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5402] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1447] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1185] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 888] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 943] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 979] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 739] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2607] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072]
*** Bug 133381 has been marked as a duplicate of this bug. ***
If a fix becomes available for this, we'll want to get it on the 099 branch ASAP.
Well, no, I can't see bugscape. So if there are any useful testcases or other information on that bug it might be useful to put them here too. I recall one of the duplicates above having a reproducable testcase -- I just have to find it again.
not much useful in the bugscape bug... just this test case that seems to be hard to reproduce. 2) go to URL http://www.ibm.com 3) click on the "IBM e-business" link (or the red "e") on the middle-right side of the page 4) click on the "Glossary" link on the middle-left side of the page 5) quickly click the back arrow a couple of times and the forward arrow a couple of times between the IBM pages Expected result: Pages attempt to load while user clicks back/forward arrows quickly; but no gpf. Actual result: GPF in GKCONTENT.DLL
FWIW, this bug still occurs for me with 2002032603 on Win2k (100% reproducible). You may be able to get it to reproduce for you also by overwriting your prefs.js with mine (attachment 73251 [details]). Then, to reproduce: 1. Delete <moz-dir>/bin 2. Unzip latest nightly into <moz-dir> 3. Load Mozilla 4. Start MailNews (I happen to do this via Ctrl-2, though I doubt this matters) 5. Mozilla crashes Note: The crash only happens the first time through the sequence, just after installing a new build. Going through the steps again after the first crash, nothing bad happens. PS Talkback ID for my most recent crash (with 2002032603) is TB4507318W.
------- Additional Comment From jen kobayashi 2002-03-25 14:24 ------- I can repro this in the following: mfcembed 099 (3/25 build) netscape 099 (3/25 build)
dbaron: Bug 131396 (a duplicate of this bug) has a testcase attached. It also provides a very easy way of crashing the browser (go to http://www.dube.com, click on printed catalog). Hope that helps.
Yes, that's the one I was thinking of. I'll try to look at this tomorrow.
www.dube.com doesn't crash for me on the trunk build. It does assert all over the place in FindCanvasBackground though: NS_ASSERTION(bodyContent, "no body node"); // bug 118829
I tried a bit to reproduce this, and I couldn't. Considering that I've already gone through code once blindly in an attempt to fix this, I'm not sure where that leaves me. I don't expect to have too much time to look at this, so I'm probably not going to be able to fix it in the near future. Marc, any interest in taking this back?
If TB4546063G is this bug, this is 50% reproducable for me on build 2002032603 on Win2k with these steps: * Make sure you have some unread messages in a mail folder but no unread messages in any newsgroups. * Select a message in a newsgroup and hit the 'n' key. * When you are asked if you want to jump to the unread message in your local mail folder, click Yes.
Attached patch another shot in the dark (obsolete) — Splinter Review
Unlikely (although perhaps possible) to be the fix to *this* crash, but it seems like this could lead to crashes.
Yea, I'll take it back. It is interesting that the latest talkback shows that the crash is in resolving style on a non-element: else if (pseudoTag == nsHTMLAtoms::mozNonElementPseudo) { aPresContext->ResolveStyleContextForNonElement(newContext, PR_TRUE, &undisplayedContext); } This narrows the field a bit, maybe.
Assignee: dbaron → attinasi_layout
Be careful with line numbers from talkback: for C++ files in Windows crash reports it reports the line-after rather than the correct line.
Thanks David.
Status: NEW → ASSIGNED
Marc, Is it possible to provide an ETA on this bug fix?
[adt1] - topcrash
Whiteboard: [adt1]
I cannt provide an ETA at this time, but it is my top priority. I will provide information as I learn it.
David's patch is a winner. Forgetting to clear the mLastLookup member is a big mistake because subsequent retrievals of anything from the hash table could end up using the stale pointer that just might retain the old memory values. Basically, any time the hash table is modified that member has to be cleared, and that was the one spot where it was missing - good catch. I incorporated that patch with some other changes that might help narow down where this is occuring. I check for whether or not he undisplayed element is HTML or not, though the same action occurs either way. In the talkbacks, the stack will show different line numbers for HTML vs non-HTML (XUL) elements, and that could be a good clue. I also added some UNDISPLAYED_MAP debug code that is off by default, and two assertions in he manipulations of the UndisplayedMap. The most important one is in ClearUndisplayedContentIn, wher I added a DEBUG check to make sure that there are no more entries for the same content after the removal has succeeded. This should never happen. David's patch may fix this bug, if not it is still correct and, like he menioned, will prevent some other crash somewhere. The other stuff I added will not fix the bug but might help to determine what situations we are dying in. I'll attach the patch.
The reason I don't think it would fix this bug is that: * |mLastLookup| is used only by comparing with another content node an using it if the pointers are equal * this crash is due to a bad pointer to a content node. So if mLastLookup is pointing to dangling memory, we'll ignore it. At least I *think* from my memory of when I wrote the patch.
Actually, it is possible that it could fix this crash, since UndisplayedMap::GetEntryFor could return the bogus mLastLookup result to UndisplayedMap::RemoveNode[s]For, causing nodes not to be removed. So I think it's worth checking in, although it's definitely also possible that it's not the problem.
There's also a chance this could be related to the last part of bug 52334 comment 85 -- incorrect ContentRemoved notifications.
Would it be OK to mark the 03/12/02 patch as obsolete. I'm trying to get a better list of driver approved patches still pending checkin and it looks like that one has already landed. Thanks.
Comment on attachment 77053 [details] [diff] [review] PATCH: incorporates David's patch and some code to help identify the content type in subsequent talkbacks (HTML vs. XUL) in case it is not actually fixed r=dbaron (assuming the bit I wrote has r=attinasi)
Attachment #77053 - Flags: review+
Comment on attachment 77053 [details] [diff] [review] PATCH: incorporates David's patch and some code to help identify the content type in subsequent talkbacks (HTML vs. XUL) in case it is not actually fixed r=attinasi on David's part of the patch
Comment on attachment 77053 [details] [diff] [review] PATCH: incorporates David's patch and some code to help identify the content type in subsequent talkbacks (HTML vs. XUL) in case it is not actually fixed sr=kin@netscape.com
Attachment #77053 - Flags: superreview+
edt0.9.9+ (plus'ing) for branch inclusion
Keywords: edt0.9.9edt0.9.9+
Comment on attachment 77053 [details] [diff] [review] PATCH: incorporates David's patch and some code to help identify the content type in subsequent talkbacks (HTML vs. XUL) in case it is not actually fixed a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77053 - Flags: approval+
If the fix is ready please push to the 099 branch.
Patch checked into trunk: /cvsroot/mozilla/layout/html/base/src/nsFrameManager.cpp,v <-- nsFrameManager.cpp new revision: 1.115; previous revision: 1.114 (leaving open for branch checkin and for later removal of the temporary branch code)
Checked into the 0.9.9 branch as well.
bug 134962 opened as a reminder to remove the temporary code, so marking this one FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
KW: fixed0.9.9 per attinasi note
Keywords: fixed0.9.9
--> adt1.0.0 - asking forgiveness actually, I alredy checked this in ;)
Keywords: adt1.0.0
Re-opening: there is a talkback (4797950) showing this crash using build 2002040308, where the potential fix is already in place. Unfortunately, there is only one talkback and it is from Linux so there are no line numbers, hence the extra branch I added is not helping. I'll wait for a Windows crash to showup in the talkback and see what more we can learn...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 77053 [details] [diff] [review] PATCH: incorporates David's patch and some code to help identify the content type in subsequent talkbacks (HTML vs. XUL) in case it is not actually fixed obsolete as it was already checked in - but apparently did not fix it :(
Attachment #77053 - Attachment is obsolete: true
I have a talkback fom Windows ME that relate to this bug. Talkback tb4821985G This is a reproducable crash in mail still occuring in 2002040403. Requires a new mail messgage to exist in a subfolder and an empty inbox when stating mail, if the next unread folder is selected by toolbar or menu - mozilla crashes. Initial details were in bug 130720 - a duplicate of this.
Gavin, that does not crash for me! I followed the directions closely, tried half a dozen times, no crash. Are you using POP or IMAP?
Status: REOPENED → ASSIGNED
Blocks: 134771
Removing adt1.0.0. Pls renominate when you have a new fix in hand, with reviews.
Keywords: adt1.0.0
These stack traces are still occuring in both the trunk and M099 builds. Here's a stack trace from windows build 2002040406 It's from incident ID 4821985 User Comments Mail - Moving into next unread folder - bugs 130720 / 118014 / 134962 nsXULElement::GetID [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3806] RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp, line 3296] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1069] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 973] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1811] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1901] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1901] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1945] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5375] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5399] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1447] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1185] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 888] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 943] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 979] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 739] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 609] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] KERNEL32.DLL + 0x248f7 (0xbff848f7) 0x00648c16 0x00058f64 ========================================================= Here is a stack trace from windows build 2002040210 It's from incident ID 4794300 RuleProcessorData::RuleProcessorData [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp, line 3277] StyleSetImpl::ResolveStyleFor [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1069] nsPresContext::ResolveStyleContextFor [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp, line 973] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1760] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1844] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1844] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1888] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5375] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5399] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1447] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 1185] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 888] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 943] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 979] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp, line 739] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2812] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1434] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1769] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1787] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326)
Was the test case (http://bugzilla.mozilla.org/show_bug.cgi?id=118014#c71) used to verify fix? Removing fixed099 KW
The email account is POP. I crash any time moving to the next unread mail in a subfolder of the inbox, as long as there have been no messages in the main inbox. Usually the crash is reported as a GPF in various dlls or unknown - but I have had one instance where the crash was a Microsoft Visual C++ Runtime Library R6025 - pure virtual function call error. This was when using a simple local mail start page (ALSO NOTE: using no mail start page there is no crash). I have again re-installed a new nightly but still crash (talkback 4877157E). This time I uninstalled mozilla, removed all the program directories - but also removed all the application data and profile information from the windows application data folder, in case there was something corrupt in my settings / mailbox etc. But as I say, it still crashes when starting from fresh (no program or data files) these were the steps I took: 1. install mozilla (talkback enabled 2002040503 - using mozilla-win32-installer.exe) 2. start mail-news 3. set up the pop mail account 4. create a subfolder of the inbox named mt 5. create a filter so any mail with the subject including [mt] goes to the mt subfolder 6. send a mail to the pop account where subject includes [mt] 7. get msgs 8. restart mozilla 9. start mail-news - there is the [mt] message in subfolder BUT NO MESSAGES IN THE MAIN INBOX 10. Click next button 11. Accept move to next unread message in mt folder The focus of the top right message-list pane goes to the [mt] message. The preview pane goes blank, removing the mail default start page, but message does not preview. Then the program crashes. Are there further things I can do to investigate this in greater detail?
Since the patch above was checked in, there have been some crashes at nsFrameManager::ReResolveStyleContext. It looks like the crashes are dereferencing |theContent|. I guess that doesn't seem too surprising since that's exactly what crashed a few functions in before.
OK, I can reproduce this now (at least I did once). Sure enough, the content from the undisplayed map is invalid, causing the crash. I'm wondering if there is some anonymous content that is put in the map and then later removed without being removed from the undisplayed map... At least now I have something to debug.
Forgot to mention, in my crash case, the localContent for the entry in the undisplayed an a XUL Element who's parent is the HTMLElement. To get rid of any remaining suspicion of the mLastLookup entry being a problem I removed it's use (temporarily) so that we always have to look up every request for an entry. This changed nothing. So, suspecting that one of the entries in the map is just plain stale (eg. the content was destroyed but the undisplayed map was not updated) I added a simple call to clear the undisplayed map unconditionally in nsPresShell::ReconstructStyleData, like we do if we are rebuilding the whole style tree. This fixed the crash and seems to still look correct.
The XUL element that is destroyed but remains in the map is getting destroyed in nsBindingManager::ChangeDocumentFor. It is anonymous content. I'm not sure just how the binding manager stuff works, but I'm digging.
The single incident from 4/3 at RuleProcessorData::RuleProcessorData was the last one reported by Talkback for that stack signature...since the checkin, we have started to see crashes at FrameManager::ReResolveStyleContext as dbaron mentioned in comment #111. Since this appears to be a result from the original patch...adding [@ FrameManager::ReResolveStyleContext] to the summary for tracking.
Summary: Trunk M099 crashes [@ RuleProcessorData::RuleProcessorData][@ nsXULElement::GetID] → Trunk M099 crashes [@ FrameManager::ReResolveStyleContext] [@ RuleProcessorData::RuleProcessorData][@ nsXULElement::GetID]
Here's the latest from Talkback for the new crashes: FrameManager::ReResolveStyleContext 23 105619 RESO FIXE dbaron@fas.harvard.edu mozilla0.9.9 2002-03-14 111061 RESO DUPL attinasi@netscape.com --- 2001-11-27 116022 RESO DUPL hyatt@netscape.com mozilla0.9.9 2002-01-27 BBID range: 4796887 - 4935224 Min/Max Seconds since last crash: 8 - 66280 Min/Max Runtime: 26 - 66280 Crash data range: 2002-04-03 to 2002-04-07 Build ID range: 2002040306 to 2002040711 Keyword List : Stack Trace: FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1810] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1901] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1901] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 1945] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5375] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5399] nsDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp line 1447] CSSLoaderImpl::InsertSheetInDoc [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 1178] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 888] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 943] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 979] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSLoader.cpp line 739] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp line 163] nsStreamListenerTee::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp line 25] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp line 2812] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1078] USER32.dll + 0x3c076 (0x77d7c076) USER32.dll + 0x3c076 (0x77d7c076) _except_handler3() kernel32.dll + 0x3bb86 (0x77e9bb86) Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsFrameManager.cpp line : 1810 (4877261) Comments: mailnews trying to delete spam which is of course the only reason i read email (4862499) Comments: I had just clicked on the Mozilla browser icon (I believe maybe it was the Mozilla Mail icon) when the QA message came up. (4825577) URL: www.tficomputer.it (4802937) Comments: reading mail - advancing to the new message in IMAP folder
adding myself.
I'm still not sure how to deal with the binding manager destroying the anonymous content, but if we are really hoping to branch today, then it might be worthwhile to put in the (temporary) shotgun fix and always clear the undisplayed map during a ReconstructStyleData call. Any opinions on that?
Patch fixes the bug by clearing the entire undisplayed map, thus clearing the stale content as well. This is all I feel comfortable with until I learn what is happening with the binding manager. The comment should make it clear that this is a temporary fix until the root problem can be addressed.
Looks like we have a possible patch for this one. Can we add an ETA to the Status Whiteboard for when this might be resolved?
Whiteboard: [adt1] → [adt1] [ETA ??/??]
ETA today - just waiting for reviews...
Whiteboard: [adt1] [ETA ??/??] → [adt1] [ETA 04/10]
I think clearing the undisplayed content map in this function is wrong whether or not we're rebuilding the rule tree, since it will prevenus from correctly reresolving any style changes on something that should be redisplayed, and I suspect it was probably put in there for the rebuilding rule tree case because of problems like this (although perhaps because of the old, now fixed, bug in ReResolveStyleContext that it didn't update the style context on the undislayed node when it reresolved it). So I suspect this could cause some additional correctness errors, but since we haven't observed any problems resulting from the current code (or have we?) this seems like a reasonable fix in the short term, so r=dbaron. Could you also back out that additional branch that you put in to get information from talkback line numbers, though (in an earlier patch on this bug)? We probably need to file two new bugs: one to get the XBL anonymous content to send the correct ContentRemoved notifications, and one to remove this clearing of the undisplayed map completely (which should depend on the first).
I wrote: > I suspect it was probably put in there for the rebuilding rule tree case > because of problems like this (although perhaps because of the old, now > fixed, bug in ReResolveStyleContext that it didn't update the style > context on the undislayed node when it reresolved it). Actually, it was almost certainly because of the bug in ReResolveStyleContext, and probably not because of this problem.
I'll open a new bug about the XBL anonymous content not being removed, and include a note in there about removing the call to ClearUndisplayedContentMap (can we make that method private to the frameManager?). And yes, I'll back out the artificial branching that I put in too. Thanks.
Bug 136704 opened for the XBL content issue
This fix doesn't seem right to me. What dbaron said is true. ReconstructStyleData doesn't reframe any more, and therefore it shouldn't have to clear the undisplayed content map at all. If there's a problem with content being deleted without properly being removed from the map, then that's the real bug, and that's what should be fixed. BTW, I'm on vacation, so if you give the bug to me, I won't get to it until April 19 or later. :)
I opened a bug on the real issue, see comment 125. This patch is to stop the topcrash until the real fix is made, which will probably be after April 19th :)
Whiteboard: [adt1] [ETA 04/10] → [adt1] [ETA UNKNOWN] [SEEKING SR]
The testcase has a display:none block in it. The alternate stylesheet will change that to display:block, as will the button being pressed. The patch will prevent the stylesheet from making the block show up, but it will not prevent the button from making it show. Thus, the regressions I expect from this are quite minimal: if a linked stylesheet changes some display:none style to any other display value, it will not show up. If DHTL changes the display:none value, it will work - and that is by far the more common case. Considering how common the crash is, and how uncommon the regression scenario is I still think this is fine wallpaper.
Comment on attachment 78438 [details] [diff] [review] PATCH to clear the undisplayed map in PresShell::ReconstructStyleData regardless of whether or not we are reconstructing the rule tree I agree with hyatt that we really should be fixing the real problem. That said, if fixing it the real way can't be done immediately, and if preventing the crash outweighs the regression this fix will cause ... I was told that running across the regression this would cause would be pretty rare ... I'll give an sr=kin@netscape.com with the understanding that this is a very short-term fix, until someone is able to address the real problem. My one concern was the impact of this on dynamic skin switching, since I believe that loads external style sheets on the fly, but I was told that this was disabled for mozilla1.0. The only other part of the product I know that adds stylesheets on the fly is Composer. Have you tested what the impact of this change is on Composer after loading files to edit, and switching back and forth between normal and all-tags mode? If this patch does get checked in, could we add a patch that backs out these changes to bug 136704?
>Have you tested what the impact of this change is on Composer after >loading files to edit, and switching back and forth between normal and all-tags >mode? No, but I will. >If this patch does get checked in, could we add a patch that backs out these >changes to bug 136704? I could, but I think that fixing bug 136704 should result in the removal of the call to clear the undisplayed map altogether. The old way we had it was wrong too, since rebuilding the rule tree did not cause a reframe. This was noted inthe bug when I opened it.
Attachment #78438 - Flags: superreview+
Pls check this into the trunk, let it bake, and have QA verify that this is resolved and does not cause any issues.
Keywords: adt1.0.0
Whiteboard: [adt1] [ETA UNKNOWN] [SEEKING SR] → [adt1] [ETA UNKNOWN] [SEEKING SR] [m5+]
Composer works fine, switching between the four modes with various pages loaded (including the testcases). I'm guessing that the stylesheets that composer loads do not make any 'display:none' elements 'display:not-none'
adding metabug blockage
Blocks: 136384
Comment on attachment 78438 [details] [diff] [review] PATCH to clear the undisplayed map in PresShell::ReconstructStyleData regardless of whether or not we are reconstructing the rule tree a=asa (on behalf of drivers) for checkin to the 1.0 branch. We need to get this in for RC1 (happening in the next few days) To get this known problem out of the talkback data. Please land on the branch ASAP.
Attachment #78438 - Flags: approval+
Taking this bug on my hit list, as it affects more than one development team. As jaime points out below, we need an eta for the fix.
looks like they are ready to go, once they get positive feedback from QA on the trunk. setting eta for 04/15.
Whiteboard: [adt1] [ETA UNKNOWN] [SEEKING SR] [m5+] → [adt1] [ETA 04/15] [m5+]
Patch checked into trunk: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v <-- nsPresShell.cpp new revision: 3.531; previous revision: 3.530
Keywords: edt0.9.9
Chris have you had a chance to check this fix out?
Whiteboard: [adt1] [ETA 04/15] [m5+] → [adt1] [ETA 04/15] [m5+][hitlist]
Resolving as FIXED. Please add fixed1.0.0 keyword after the fix has been checked into the 1.0.0 branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: [adt1] [ETA 04/15] [m5+][hitlist] → [adt1] [ETA 04/15] [m5+][hitlist] [FIXED_ON_TRUNK]
trying to get RC1 out tomorrow. can this make the branch today?
Using the April 15th build (2002-04-15-03) under Windows ME, I can't reproduce the crash described. All urls provided in this reported have been accessed with no crash observed. Using the mail filter info provided, I couldn't reproduce the crash either.
Marking verified in the April 15th build (2002-04-15-03).Tested under Windows ME.
Status: RESOLVED → VERIFIED
adt1.0.0+ (on ADT's behalf) for checkin into the 1.0 branch. Pls check this in to the branch today. After it is checked in, pls add fixed1.0.0. Once QA has verified it on the branch, then add verified1.0.0.
Keywords: adt1.0.0adt1.0.0+
Checked into trunk: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v <-- nsPresShell.cpp new revision: 3.527.2.3; previous revision: 3.527.2.2
Keywords: fixed1.0.0
Sorry, last comment was wrong: Checked into BRANCH MOZILLA_1_0_0_BRANCH /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v <-- nsPresShell.cpp new revision: 3.527.2.3; previous revision: 3.527.2.2
Marking verified on branch OS X (2002-04-18-05) and Windows ME (2002-04-17-11) builds.
Re-tested this on netscape 4-18 100 build using the following steps: 1. navigate to www.ibm.com 2. click ebusiness link (red 'e'on right hand side of page) 3. click glossary 4. begin navigating back and forth quickly between pages Result: Crash now occurs in js3250.dll. Talkback id is: TB5484538k http://climate.mcom.com/reports/singleincidentinfo.cfm?dynamicBBID=TB5484538k Occurs in proprietary embedding client as well. Re-opening bug for further investigation! Thx - jenk
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Here is the stack from the talkback: js_FreeStack [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 409] JS_PopArguments [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 391] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 186] nsEventListenerManager::HandleEventSubType [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1218] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 1893] GlobalWindowImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 741] nsDocument::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3241] nsGenericElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1673] nsGenericElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1673] nsGenericElement::HandleDOMEvent [d:\builds\seamonkey\mozilla\content\base\src\nsGenericElement.cpp, line 1673] nsHTMLScriptElement::ScriptAvailable [d:\builds\seamonkey\mozilla\content\html\content\src\nsHTMLScriptElement.cpp, line 339] nsScriptLoadRequest::FireScriptAvailable [d:\builds\seamonkey\mozilla\content\base\src\nsScriptLoader.cpp, line 113] nsScriptLoader::FireScriptAvailable [d:\builds\seamonkey\mozilla\content\base\src\nsScriptLoader.cpp, line 505] nsScriptLoader::OnStreamComplete [d:\builds\seamonkey\mozilla\content\base\src\nsScriptLoader.cpp, line 617] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 163] nsHttpChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2829] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1431] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1766] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1784] WinMainCRTStartup() KERNEL32.DLL + 0x7903 (0x77e87903) From this stack, I have to say this looks like something very different. There is no layout in the stack... sending to events for a first look. (BTW: I still cannot duplicate it on my Win2K or Mac OS X builds using the ibm.com steps)
Assignee: attinasi_layout → joki
Status: REOPENED → NEW
Component: Layout → Event Handling
QA Contact: petersen → madhur
changing QA contact
QA Contact: madhur → rakeshmishra
How about making this new crash a different bug?
I have no problem with making this "new" crash another bug, but p;ease lets move the resolution forward. Mahdur, Please open a new bug and put me on it.
Madhur, since I am tracking this bug on a shortlist of critical beta bugs, please cc me on the new bug.
Rakesh... Could you open the "new" bug for the issue.
Opened bug 139556 with Rakesh...
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
As per Comment #147 , marking the bug "Closed"
Status: RESOLVED → CLOSED
*** Bug 128933 has been marked as a duplicate of this bug. ***
Crash Signature: [@ FrameManager::ReResolveStyleContext] [@ RuleProcessorData::RuleProcessorData] [@ nsXULElement::GetID]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: