Closed Bug 303823 Opened 19 years ago Closed 15 years ago

crash [@ nsCSSCompressedDataBlock::Destroy]

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: jaime.bugzilla, Unassigned)

References

Details

(Keywords: crash, topcrash, Whiteboard: [may be resolved, awaiting feedback])

Crash Data

This is no. 3 on the Talkback firefox trunk topcrashers. Appears to be windows only

Incident ID: 8056808
Stack Signature	nsCSSCompressedDataBlock::Destroy 38891985
Product ID	FirefoxTrunk
Build ID	2005080106
Trigger Time	2005-08-03 09:27:34.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (002b3aa0)
URL visited	
User Comments	exiting through the file menu
Since Last Crash	5780 sec
Total Uptime	5780 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDataBlock.cpp,
line 464
Stack Trace 	
nsCSSCompressedDataBlock::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDataBlock.cpp,
line 464]
nsCSSDeclaration::~nsCSSDeclaration 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDeclaration.cpp,
line 105]

A couple mention allegro.pl as the url

One of the incidents has a longer stack but may be a different crash

Incident ID: 8049404
Stack Signature	nsCSSCompressedDataBlock::Destroy 6f32432f
Product ID	FirefoxTrunk
Build ID	2005080206
Trigger Time	2005-08-03 03:45:13.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (002b363c)
URL visited	
User Comments	
Since Last Crash	3741 sec
Total Uptime	16046 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDataBlock.cpp,
line 458
Stack Trace 	
nsCSSCompressedDataBlock::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDataBlock.cpp,
line 458]
nsCSSDeclaration::~nsCSSDeclaration 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsCSSDeclaration.cpp,
line 105]
nsHTMLStyleElement::UnbindFromTree 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/html/content/src/nsHTMLStyleElement.cpp,
line 233]
nsGenericElement::UnbindFromTree 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1929]
nsGenericElement::UnbindFromTree 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1929]
nsDocument::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp,
line 4899]
DocumentViewerImpl::Close 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 1279]
nsDocShell::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 3419]
nsFrameLoader::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/base/src/nsFrameLoader.cpp,
line 219]
nsSubDocumentFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameFrame.cpp,
line 572]
nsFrameList::DestroyFrames 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameList.cpp,
line 131]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1119]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1119]
nsPositionedInlineFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsInlineFrame.cpp,
line 1091]
DocumentViewerImpl::Hide 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp,
line 1868]
nsSubDocumentFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameFrame.cpp,
line 562]
nsFrameList::DestroyFrames 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsFrameList.cpp,
line 131]
nsBoxFrame::Destroy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1119]
nsFrameManager::RemoveFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsFrameManager.cpp,
line 704]
nsCSSFrameConstructor::ContentRemoved 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 9830]
nsCSSFrameConstructor::RecreateFramesForContent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 11692]
nsCSSFrameConstructor::RestyleElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 10263]
nsCSSFrameConstructor::ProcessOneRestyle 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13652]
nsCSSFrameConstructor::ProcessPendingRestyles 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13700]
nsCSSFrameConstructor::RestyleEvent::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13753]
0x778b0c24
0x000d000a
Nominating as a blocker based on Talkback data
Flags: blocking1.8b4?
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b4? → blocking1.8b4+
The bulk of the stacks in talkback are useless, and the raw stack data and
registers aren't available in the full internal talkback info, so it's hard to
figure out what's happening.
The longer stack here doesn't make a whole lot of sense, either.  At a minimum
it seems like there's a bit of a gap.  But it could provide a clue.
Bz,

Can you take a look?
Assignee: nobody → bzbarsky
I did.  I have no idea what's going on here, and can't reproduce (since it's
apparently windows-only and I need my one box with a windows setup booted into
Linux because I'm working on 5 or 6 different things at once right now).  I did
spend about 2 hours yesterday looking at code and trying to reproduce on Linux
and failing...

Given all that, if we've gotten nowhere on this by the time I'm done putting out
all the fires I actually _can_ put out for 1.8b4 I can try to take a look.
Assignee: bzbarsky → nobody
Until somebody has useful talkback data and confidence that those data represent
the bulk of the crash reports, this bug probably isn't going anywhere.  None of
the data on the talkback servers have the raw stack dump or the registers.
Looking at the talkback reports and trying some of the url's I am not able to
reproduce this crash on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050815
Firefox/1.0+ ID:2005081507

This crash has become much less frequent and may be fixed, there are only a few
stacks since the 11/08 build and none since 14/08. No stacks appear for the
firefox 1.5 branch (created around the 12th ?)

I suggest removing the blocking status and resolving this in a few days if no
further talkback data appears for this stack.
demoting to a nomination for 1.8b4 pending analysis of talkback data, may well
be resolved fixed per comment #8
Flags: blocking1.8b4+ → blocking1.8b4?
Whiteboard: [may be resolved, awaiting feedback]
please renominate if we get better data after beta.
Flags: blocking1.8b4? → blocking1.8b4-
*** Bug 335697 has been marked as a duplicate of this bug. ***
I can apparently reliably cause this crash (reported as duplicate bug 335697) on the 1.5 branch by logging in to MySpace.com. It seems to happen roughly one out of three times. It also occurs in other cases, but much less reliably. Strangely, this may have coincided with the recent upgrade of Thunderbird to 1.5.2. Is that possible? Do they share components or do they each have their own resources?

Note that it only sometimes generates talkback data; most of the time, it crashes and the browser closes with no warning. If the talkback from bug 335697 is not useful, I can try to generate some more if it will help fix this problem. Unfortunately this is blocking me from performing some testing of web applications because it will often spontaneously close what I'm working on (along with all other open tabs/windows).
Assignee: nobody → dbaron
Component: Layout → Style System (CSS)
QA Contact: layout → ian
FWIW, for me, it does not appear to be resolved as of 1.5.0.4.
(In reply to comment #12)
> I can apparently reliably cause this crash (reported as duplicate bug 335697)
> on the 1.5 branch by logging in to MySpace.com.

What's needed to reproduce the crash?  Do you see the crash just filling in the login form?  Do you have to submit the form?  Do you have to have filled in valid account information into the form so that it loads the "you're logged in" page (or whatever submitting the form gives you when you log in)?
Hrm, from reading bug 335697 it seems like it requires having an account, but could you confirm that?

And, since you said (bug 335697 comment 2) it doesn't happen in safe mode, what extensions do you have installed?
It does require having an account.

I checked my extensions and I noticed I had one for Mercury's Quality Center. I'm pretty sure that it was a bogus install, so I went ahead and uninstalled that plug-in, and now I can't get it to crash anymore. I also have flashblock and talkback installed. I have a feeling that it has something to do with any plug-in that isn't properly installed. This could mean that my crash actually isn't related to this bug after all. I had originally reported this problem in bug 335697. Considering that removing the bogus add-in seems to have fixed the problem (and I inexplicably never thought of checking that), this problem may be fixed after all.

It did seem to happen right after you logged in, roughly one out of three times. Since the post-login screen is a dynamic advertisement that is sometimes Flash based, my guess is that there was a piece of content that was trying to trigger my bogus add-in for some reason, and Firefox had a fit and closed w/o an error.

So, in summary, I think the problem may have been:
1. A login, followed by a page that triggered the Flash block extension
2. followed by a quick meta-refresh in combination with
3. a bogusly installed extension that was unrelated to the Flash block

Probably some sort of race condition related to the preceding steps. If it happens again, I'll comment on bug 335697 and reopen it.
Assignee: dbaron → nobody
QA Contact: ian → style-system
only #390 in the talkback ranking for FF2
Sounds like WFM/INCO to me, except possibly for the bug 335697 part (which jesse strachman will reopen if needed).
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Crash Signature: [@ nsCSSCompressedDataBlock::Destroy]
You need to log in before you can comment on or make changes to this bug.