Closed Bug 309307 Opened 20 years ago Closed 12 years ago

WARNING: NS_ENSURE_TRUE(scount != 0) failed, file ../../../../../mozilla/parser/htmlparser/src/nsDTDUtils.cpp, line 297

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.9alpha1

People

(Reporter: Biesinger, Unassigned)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

Fix the bogus patch
4.37 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review
linux, gtk2, seamonkey, trunk, checkout finish: So Sep 18 22:29:45 CEST 2005 Loading http://www.mozilla.org shows the warning: WARNING: NS_ENSURE_TRUE(scount != 0) failed, file ../../../../../mozilla/parser/htmlparser/src/nsDTDUtils.cpp, line 297
I'll try to figure out what this means.
Assignee: parser → mrbkap
QA Contact: mrbkap → parser
There are at least 2 causes for this warning. I've found one of them so far.
Status: NEW → ASSIGNED
Attached patch Don't miss the 0th index (obsolete) — — Splinter Review
I have to admit that I don't entirely understand what's going on here. I'm pretty convinced this fix is correct for this problem, however. I hit the warning on the testcase: |<body><object><b><div> </object>| (the space is important) because we're not updating one of the style entry's parent pointers, causing us to try to remove it from that style stack twice. This seems to fix the warning (assertion for me! ;-)) on http://www.mozilla.org.
Attachment #197869 - Flags: review?(jst)
If we didn't find the style entry on its parent (I don't know how this happens yet), we would crash with the old patch.
Attachment #197869 - Attachment is obsolete: true
Attachment #197879 - Flags: review?(jst)
Attachment #197869 - Flags: review?(jst)
Comment on attachment 197879 [details] [diff] [review] Fix the bogus patch r+sr=jst
Attachment #197879 - Flags: superreview+
Attachment #197879 - Flags: review?(jst)
Attachment #197879 - Flags: review+
Attachment 197879 [details] [diff] checked in. Leaving this bug open to investigate the second cause of this warning.
Flags: blocking1.9a1?
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha
Flags: blocking1.9a1? → blocking1.9-
Assignee: mrbkap → nobody
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
It isn't worth fixing the second cause of this anymore.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: