Closed Bug 212364 Opened 22 years ago Closed 7 years ago

Removing a listbox from a xul document causes a crash [@ nsSupportsHashtable::ReleaseElement]

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: mscott, Assigned: janv)

Details

(Keywords: crash, Whiteboard: [tbird crash][needs xul layout hacker to answer comment 2])

Crash Data

I've got the following situation in thunderbird: 1) a listbox is inside of a box (http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/msgHdrViewOverlay.xul#144) 2)elements are dynamically added to the list box, this causes nsPresState::SetStatePropertyAsSupports to store a nsListBoxBodyFrame object as an nsISupports element in the pres state property hash table. Note: frames are not ref counted. 3)I later want to re-parent the containing box so I call removeChild to remove the box (and indirectly the listbox) from the current document. During the call to removeChild, we no longer have an owning document for the box and the list box so we end up destroying all of the frames for these elements. This means our nsListBoxBodyFrame introduced back in step 2 has been deleted. But our pres state property hash table still has a 'reference' to this deleted frame. After the frames are destroyed, the box object releases the pres state which in turn trys to release all of the properties in it's hash table, including our already deleted object. Full stack trace: nsSupportsHashtable::ReleaseElement(nsHashKey * 0x0104eab8, void * 0x0321412c, void * 0x00000000) line 796 + 15 bytes hashEnumerate(PLDHashTable * 0x02c8c870, PLDHashEntryHdr * 0x0104ea34, unsigned int 0, void * 0x0012d270) line 115 + 26 bytes PL_DHashTableEnumerate(PLDHashTable * 0x02c8c870, int (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* 0x1001b560 hashEnumerate(PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *), void * 0x0012d270) line 594 + 34 bytes nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x1001c9a0 nsSupportsHashtable::ReleaseElement(nsHashKey *, void *, void *), void * 0x00000000) line 303 + 21 bytes nsSupportsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x1001c9a0 nsSupportsHashtable::ReleaseElement(nsHashKey *, void *, void *), void * 0x00000000) line 202 nsSupportsHashtable::~nsSupportsHashtable() line 803 nsSupportsHashtable::`scalar deleting destructor'(unsigned int 1) + 16 bytes nsPresState::~nsPresState() line 94 + 33 bytes nsPresState::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsPresState::Release(nsPresState * const 0x02c8c810) line 84 + 179 bytes nsCOMPtr<nsIPresState>::assign_assuming_AddRef(nsIPresState * 0x00000000) line 456 nsCOMPtr<nsIPresState>::assign_with_AddRef(nsISupports * 0x00000000) line 958 nsCOMPtr<nsIPresState>::operator=(nsIPresState * 0x00000000) line 569 nsBoxObject::SetDocument(nsBoxObject * const 0x02c8c764, nsIDocument * 0x00000000) line 146 nsDocument::SetBoxObjectFor(nsDocument * const 0x02a80a70, nsIDOMElement * 0x02c1d6f4, nsIBoxObject * 0x00000000) line 2965 nsXULElement::SetDocument(nsXULElement * const 0x02c1d6f0, nsIDocument * 0x00000000, int 1, int 1) line 1872 nsXULElement::SetDocument(nsXULElement * const 0x02c1d600, nsIDocument * 0x00000000, int 1, int 1) line 1940 nsXULElement::SetDocument(nsXULElement * const 0x02c92f98, nsIDocument * 0x00000000, int 1, int 1) line 1940 nsXULElement::SetDocument(nsXULElement * const 0x02bd3028, nsIDocument * 0x00000000, int 1, int 1) line 1940 nsXULElement::SetDocument(nsXULElement * const 0x02bd2ec8, nsIDocument * 0x00000000, int 1, int 1) line 1940 nsXULElement::RemoveChildAt(nsXULElement * const 0x02bd06c8, int 1, int 1) line 2289 nsXULElement::RemoveChild(nsXULElement * const 0x02bd06cc, nsIDOMNode * 0x02bd2ecc, nsIDOMNode * * 0x0012d930) line 1104 + 22 bytes
Frames shouldn't be used as nsISupports like this unless the caller is very careful to remove them if needed.
Assignee: frame → varga
Component: Layout: HTML Frames → XP Toolkit/Widgets: Trees
QA Contact: madhur → shrir
Keywords: crash
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
Does the listbox code still do this crazy thing? Sounds a bit like bug 488771, fwiw. nsPresState::SetStatePropertyAsSupports doesn't seem to exist any more.
Whiteboard: [needs xul layout hacker to answer comment 2]
Summary: Removing a listbox from a xul document causes a crash [nsSupportsHashtable::ReleaseElement] → Removing a listbox from a xul document causes a crash [@ nsSupportsHashtable::ReleaseElement]
Crash Signature: [@ nsSupportsHashtable::ReleaseElement]
https://crash-stats.mozilla.com/report/list?signature=nsSupportsHashtable%3A%3AReleaseElement%28nsHashKey*%2C+void*%2C+void*%29 at least says there's still crashes happening in that function... Not sure if those are the same thing or not. Should this bug be resolved or kept open for those?
Crash Signature: [@ nsSupportsHashtable::ReleaseElement] → [@ nsSupportsHashtable::ReleaseElement] [@ nsSupportsHashtable::ReleaseElement(nsHashKey*, void*, void*) ]
(In reply to Robert Kaiser from comment #3) > https://crash-stats.mozilla.com/report/ > list?signature=nsSupportsHashtable%3A%3AReleaseElement%28nsHashKey*%2C+void*% > 2C+void*%29 at least says there's still crashes happening in that > function... Nothing in crash-stats in the last six months. > Not sure if those are the same thing or not. Should this bug be > resolved or kept open for those? Jorg, have an opinion?
Severity: normal → critical
Flags: needinfo?(jorgk)
Whiteboard: [needs xul layout hacker to answer comment 2] → [tbird crash][needs xul layout hacker to answer comment 2]
The listbox element was removed from M-C recently. I'd close this ancient bug which hasn't had any action since 2012.
Flags: needinfo?(jorgk)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.