Closed Bug 7940 Opened 25 years ago Closed 25 years ago

Crash in JavaScript garbage collection

Categories

(Core :: JavaScript Engine, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: fur, Assigned: jband_mozilla)

References

Details

(Originally filed as bug #7545)

Akkana and I tried briefly to reproduce the crash-in-JavaScript GC and were
unable.  If someone knows how to make this happen, please update the bug.

------- Additional Comments From cmanske@netscape.com  06/08/99 15:12 -------
I'm seeing a crash after launching apprunner, then Editor, then closing
Editor window, then closing Apprunner (no interaction with editor).
Here's a stack:
gc_root_marker(JSHashEntry * 0x03099de0, int 12, void * 0x017060e8) line 587 + 3
bytes
JS_HashTableEnumerateEntries(JSHashTable * 0x01367f70, int (JSHashEntry *, int,
void *)* 0x003a1f70 gc_root_marker(JSHashEntry *, int, void *), void *
0x017060e8) line 347 + 15 bytes
js_GC(JSContext * 0x01602a90) line 724 + 21 bytes
js_ForceGC(JSContext * 0x01602a90) line 618 + 9 bytes
js_DestroyContext(JSContext * 0x01602a90) line 130 + 9 bytes
JS_DestroyContext(JSContext * 0x01602a90) line 690 + 9 bytes
nsJSContext::~nsJSContext() line 116 + 13 bytes
nsJSContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsJSContext::Release(nsJSContext * const 0x01602a50) line 120 + 96 bytes
nsWebShell::~nsWebShell() line 582 + 27 bytes
nsWebShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsWebShell::Release(nsWebShell * const 0x015ff120) line 646 + 95 bytes
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 465 + 18 bytes
nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::DeleteFrame(nsFrame * const 0x015fe520, nsIPresContext & {...}) line
390 + 34 bytes
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x015fbba0,
nsIPresContext & {...}) line 82
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x01727fc8,
nsIPresContext & {...}) line 82
nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x015fcaf0) line
158
nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x015f7f20, nsIPresContext &
{...}) line 806 + 16 bytes
nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x015f7f20, nsIPresContext & {...})
line 106
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x015f6d80,
nsIPresContext & {...}) line 82
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x015f6b90,
nsIPresContext & {...}) line 82
ViewportFrame::DeleteFrame(ViewportFrame * const 0x015f6b90, nsIPresContext &
{...}) line 116
PresShell::~PresShell() line 549
PresShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes
PresShell::Release(PresShell * const 0x015d9890) line 485 + 34 bytes
nsCOMPtr_base::~nsCOMPtr_base() line 26
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() + 15 bytes
DocumentViewerImpl::~DocumentViewerImpl() line 242 + 22 bytes
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x01598f50) line 184 + 99
bytes
nsWebShell::Destroy(nsWebShell * const 0x015b2af0) line 962 + 27 bytes
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 465
nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::DeleteFrame(nsFrame * const 0x015b2900, nsIPresContext & {...}) line
390 + 34 bytes
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x01572a60,
nsIPresContext & {...}) line 82
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x01779f08,
nsIPresContext & {...}) line 82
nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x015974f0) line
158
nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x014f5ef0, nsIPresContext &
{...}) line 806 + 16 bytes
nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x014f5ef0, nsIPresContext & {...})
line 106
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x0146c120,
nsIPresContext & {...}) line 82
nsFrameList::DeleteFrames(nsIPresContext & {...}) line 29
nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x014fd120,
nsIPresContext & {...}) line 82
ViewportFrame::DeleteFrame(ViewportFrame * const 0x014fd120, nsIPresContext &
{...}) line 116
PresShell::~PresShell() line 549
PresShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes
PresShell::Release(PresShell * const 0x013bea40) line 485 + 34 bytes
nsCOMPtr_base::~nsCOMPtr_base() line 26
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() + 15 bytes
DocumentViewerImpl::~DocumentViewerImpl() line 242 + 22 bytes
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x01364a50) line 184 + 99
bytes
nsWebShell::Destroy(nsWebShell * const 0x01300aa0) line 962 + 27 bytes
[more... this should be enough!]


------- Additional Comments From law@netscape.com  06/09/99 09:54 -------
I have been seeing crashes in JavaScript GC code when closing windows, too.  I'd
really like to assign this to somebody capable of diagnosing why this happens.
My suspicion is that this would be a JavaScript guru.  If it turns out to be due
to some abuse of JavaScript by somebody higher up the food-chain, then it can be
assigned back to the xptoolkit or xpapps team.

I'll be looking to find somebody better suited to deal with this and will
reassign it when I find them.  Of course, volunteers are welcome to take it.
Component: JavaScript → Javascript Engine
Javascript component no longer in use per Dev team...component to disappear
soon.  Moved to Javascript Engine.
QA Contact: leger → cbegle
Blocks: 7222
*** Bug 7649 has been marked as a duplicate of this bug. ***
Assignee: fur → jband
reassigning to me
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
checked in fix.

Notification in xpconnect of JSContext about to be destroyed was zeroing out
information later used to remove gc root. This was keeping JS_RemoveRoot from
being called for those objects. So, the JSRuntime was getting left with pointers
to roots for stuff on JSContexts long since destroyed and for which memory had
been recycled. The fix is to be *sure* to do all the proper cleanup in xpconnect
upon notification that a JSContext is about to be destroyed.
Blocks: 7799
Target Milestone: M7
Moving onto M7 milestone since you are checking it in now.
well, i was never able to reproduce this with any regularity, so even though
i'm not seeing it now, i'm loathe to mark this verified.  if anyone else is
still seeing this, please re-open it. other wise, i'll mark it verified in a
while.
Can't find any open bugs of crashes with this anymore.  Though there are a few
layout problems.  Probably safe to mark Verified now.
Status: RESOLVED → VERIFIED
great
You need to log in before you can comment on or make changes to this bug.