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)
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+
asa
:
approval+
|
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.
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.
Comment 8•23 years ago
|
||
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.
Checkins in that time period:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2001-12-18+08%3A00&maxdate=2001-12-19+08%3A00&cvsroot=%2Fcvsroot
This could certainly have been something exposed by the theme rewrites, and it
could also be related to hyatt's checkin for bug 115787.
Comment 11•23 years ago
|
||
*** 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
Comment 13•23 years ago
|
||
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).
Comment 14•23 years ago
|
||
*** Bug 121103 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.9
*** Bug 122276 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 119375 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
*** Bug 125032 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
*** Bug 125752 has been marked as a duplicate of this bug. ***
*** Bug 125579 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
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]
Comment 23•23 years ago
|
||
>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
Comment 24•23 years ago
|
||
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!
Comment 25•23 years ago
|
||
Assignee: attinasi → attinasi_layout
Status: ASSIGNED → NEW
Comment 26•23 years ago
|
||
rolling forward to 1.0
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 27•23 years ago
|
||
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).
Comment 28•23 years ago
|
||
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
**********
Comment 29•23 years ago
|
||
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]
Reporter | ||
Comment 30•23 years ago
|
||
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.
Comment 31•23 years ago
|
||
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
Comment 32•23 years ago
|
||
What is our latest talkback on this bug? Can we close it as fixed or WFM?
Comment 33•23 years ago
|
||
Is TB3766051G this bug? If so, I can still reproduce this on build 2002-03-06-04
using the steps from bug 122276.
Reporter | ||
Comment 34•23 years ago
|
||
Marc, this one has 200+ crashes on M098 and 65 on the Trunk currently. I don't
think we should close it as WFM ;-)
Reporter | ||
Comment 35•23 years ago
|
||
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.
Reporter | ||
Comment 36•23 years ago
|
||
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.
Comment 37•23 years ago
|
||
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.
Comment 38•23 years ago
|
||
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
Comment 39•23 years ago
|
||
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.
Comment 40•23 years ago
|
||
Comment 41•23 years ago
|
||
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?
Comment 45•23 years ago
|
||
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.
Attachment #73361 -
Attachment is obsolete: true
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 51•23 years ago
|
||
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 55•23 years ago
|
||
Comment on attachment 73740 [details] [diff] [review]
cover the ReplaceFrame callers too
r=kin@netscape.com
Attachment #73740 -
Flags: review+
Comment 56•23 years ago
|
||
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.
Comment 58•23 years ago
|
||
*** 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.
Comment 60•23 years ago
|
||
*** Bug 131396 has been marked as a duplicate of this bug. ***
Comment 61•23 years ago
|
||
*** Bug 130629 has been marked as a duplicate of this bug. ***
Comment 62•23 years ago
|
||
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.
Comment 64•23 years ago
|
||
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.
Comment 65•23 years ago
|
||
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]
Comment 66•23 years ago
|
||
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. ***
Comment 68•23 years ago
|
||
See Bugscape:
http://bugscape.netscape.com/show_bug.cgi?id=12741
Comment 69•23 years ago
|
||
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.
Comment 71•23 years ago
|
||
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
Comment 72•23 years ago
|
||
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.
Comment 73•23 years ago
|
||
------- 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)
Comment 74•23 years ago
|
||
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.
Comment 76•23 years ago
|
||
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?
Comment 78•23 years ago
|
||
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.
Unlikely (although perhaps possible) to be the fix to *this* crash, but it
seems like this could lead to crashes.
Comment 80•23 years ago
|
||
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.
Comment 83•23 years ago
|
||
Marc, Is it possible to provide an ETA on this bug fix?
Comment 85•23 years ago
|
||
I cannt provide an ETA at this time, but it is my top priority. I will provide
information as I learn it.
Comment 86•23 years ago
|
||
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.
Comment 90•23 years ago
|
||
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.
Attachment #73740 -
Attachment is obsolete: true
Comment 91•23 years ago
|
||
Attachment #76509 -
Attachment is obsolete: true
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 93•23 years ago
|
||
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 94•23 years ago
|
||
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+
Comment 95•23 years ago
|
||
edt0.9.9+ (plus'ing) for branch inclusion
Comment 96•23 years ago
|
||
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+
Comment 97•23 years ago
|
||
If the fix is ready please push to the 099 branch.
Comment 98•23 years ago
|
||
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)
Comment 99•23 years ago
|
||
Checked into the 0.9.9 branch as well.
Comment 100•23 years ago
|
||
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
Comment 102•23 years ago
|
||
--> adt1.0.0 - asking forgiveness actually, I alredy checked this in ;)
Keywords: adt1.0.0
Comment 103•23 years ago
|
||
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 104•23 years ago
|
||
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
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
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
Comment 107•23 years ago
|
||
Removing adt1.0.0. Pls renominate when you have a new fix in hand, with reviews.
Keywords: adt1.0.0
Comment 108•23 years ago
|
||
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)
Comment 109•23 years ago
|
||
Was the test case (http://bugzilla.mozilla.org/show_bug.cgi?id=118014#c71) used
to verify fix?
Removing fixed099 KW
Comment 110•23 years ago
|
||
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.
Comment 112•23 years ago
|
||
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.
Comment 113•23 years ago
|
||
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.
Comment 114•23 years ago
|
||
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.
Comment 115•23 years ago
|
||
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]
Comment 116•23 years ago
|
||
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
Comment 117•23 years ago
|
||
adding myself.
Comment 118•23 years ago
|
||
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?
Comment 119•23 years ago
|
||
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.
Comment 120•23 years ago
|
||
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 ??/??]
Comment 121•23 years ago
|
||
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).
Attachment #78438 -
Flags: review+
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.
Comment 124•23 years ago
|
||
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.
Comment 125•23 years ago
|
||
Bug 136704 opened for the XBL content issue
Comment 126•23 years ago
|
||
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. :)
Comment 127•23 years ago
|
||
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 :)
Updated•23 years ago
|
Whiteboard: [adt1] [ETA 04/10] → [adt1] [ETA UNKNOWN] [SEEKING SR]
Comment 128•23 years ago
|
||
Comment 129•23 years ago
|
||
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 130•23 years ago
|
||
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?
Comment 131•23 years ago
|
||
>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+
Comment 132•23 years ago
|
||
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+]
Comment 133•23 years ago
|
||
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'
Comment 135•23 years ago
|
||
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+
Comment 136•23 years ago
|
||
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.
Comment 137•23 years ago
|
||
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+]
Comment 138•23 years ago
|
||
Patch checked into trunk:
/cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v <-- nsPresShell.cpp
new revision: 3.531; previous revision: 3.530
Comment 139•23 years ago
|
||
Chris have you had a chance to check this fix out?
Updated•23 years ago
|
Whiteboard: [adt1] [ETA 04/15] [m5+] → [adt1] [ETA 04/15] [m5+][hitlist]
Comment 140•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Whiteboard: [adt1] [ETA 04/15] [m5+][hitlist] → [adt1] [ETA 04/15] [m5+][hitlist] [FIXED_ON_TRUNK]
Comment 141•23 years ago
|
||
trying to get RC1 out tomorrow. can this make the branch today?
Comment 142•23 years ago
|
||
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.
Comment 143•23 years ago
|
||
Marking verified in the April 15th build (2002-04-15-03).Tested under Windows ME.
Status: RESOLVED → VERIFIED
Comment 144•23 years ago
|
||
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.
Comment 145•23 years ago
|
||
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
Comment 146•23 years ago
|
||
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
Comment 147•23 years ago
|
||
Marking verified on branch OS X (2002-04-18-05) and Windows ME (2002-04-17-11)
builds.
Keywords: fixed1.0.0 → verified1.0.0
Comment 148•23 years ago
|
||
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 → ---
Comment 149•23 years ago
|
||
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
How about making this new crash a different bug?
Comment 152•23 years ago
|
||
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.
Comment 153•23 years ago
|
||
Madhur, since I am tracking this bug on a shortlist of critical beta bugs,
please cc me on the new bug.
Comment 154•23 years ago
|
||
Rakesh... Could you open the "new" bug for the issue.
Comment 155•23 years ago
|
||
Opened bug 139556 with Rakesh...
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 128933 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ FrameManager::ReResolveStyleContext]
[@ RuleProcessorData::RuleProcessorData]
[@ nsXULElement::GetID]
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•