Closed Bug 7940 Opened 26 years ago Closed 26 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: 26 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.