Closed
Bug 298725
Opened 20 years ago
Closed 20 years ago
ASSERTION: You can't dereference a NULL nsCOMPtr with operator->()
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta3
People
(Reporter: bc, Assigned: jst)
Details
(Keywords: crash, regression, Whiteboard: has patch (jst), ready to land)
Attachments
(2 files)
919 bytes,
patch
|
peterv
:
review+
peterv
:
superreview+
benjamin
:
approval1.8b3+
|
Details | Diff | Splinter Review |
1.26 KB,
patch
|
Details | Diff | Splinter Review |
I have started to get this assertion when running the DOM TS in the last two days. Jst came up with the patch I will attach next. ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/xpcom\nsCOMPtr.h, line 849
Reporter | ||
Comment 1•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Assignee | ||
Updated•20 years ago
|
Attachment #187257 -
Flags: superreview?(peterv)
Attachment #187257 -
Flags: review?(peterv)
Assignee | ||
Comment 2•20 years ago
|
||
This is a crash regression that prevents us from getting through the DOM test suite. Given that the patch is trivial we should IMO take this for 1.8b3.
Status: NEW → ASSIGNED
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Target Milestone: --- → mozilla1.8beta3
Comment 3•20 years ago
|
||
Can you explain a) why and where it crashes and b) how this fixes it? Also why isn't it needed for the call to CreateElem(nsHTMLAtoms::a, ...) just above?
Updated•20 years ago
|
Flags: blocking1.8b3?
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Whiteboard: has patch (jst), peterv needs clarification
Assignee | ||
Comment 4•20 years ago
|
||
a) We crash because we end up creating an XML element named 'img' in stead of an HTML element, and we QI that to nsIImageLoadingContent and call methods on it. The QI obviously fails, so we crash. The case we're dealing with here is an XML document that has an XHTML object (or embed) element in it, we end up calling doc->CreateElem(img, null, kNameSpaceID_XHTML, true), which makes use the document's default type when creating elements (kNameSpaceID_None) when it shouldn't use the default type at all. And yes, we should make the exact same change to the above code that creates the anchor tag, good catch.
Group: security
Comment 5•20 years ago
|
||
Comment on attachment 187257 [details] [diff] [review] patch r/sr=peterv with the change to the other CreateElem call just above.
Attachment #187257 -
Flags: superreview?(peterv)
Attachment #187257 -
Flags: superreview+
Attachment #187257 -
Flags: review?(peterv)
Attachment #187257 -
Flags: review+
Assignee | ||
Updated•20 years ago
|
Attachment #187257 -
Flags: approval1.8b3?
Updated•20 years ago
|
Attachment #187257 -
Flags: approval1.8b3? → approval1.8b3+
Updated•20 years ago
|
Whiteboard: has patch (jst), peterv needs clarification → has patch (jst), ready to land
Assignee | ||
Comment 7•20 years ago
|
||
Um, it's not. Must have checked the checkbox by mistake...
Group: security
Assignee | ||
Comment 8•20 years ago
|
||
Assignee | ||
Comment 9•20 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•