319829 - Clicking in the subheadings in the composer section of the preferences often crashes Seamonkey

Status: RESOLVED DUPLICATE of bug 319264

(Core :: JavaScript Engine, defect)

Description

[crf]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051210 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051210 SeaMonkey/1.5a

Open the preferences in Seamonkey, and click the composer section to show the subsections: New Page Settings and Toolbars. If you click on either of these settings, and then away to another setting, often Seamonkey will crash.
TB12823826Y
TB12823790W

These settings are still editable, should the program not crash.

Reproducible: Always

Steps to Reproduce:
1.Open Preferences, Click Composer section to open it, Click around the subheadings of the Composer section. 
2.
3.

Actual Results:  
Seamonkey Crashes.

Expected Results:  
It shouldn't crash simply when you click around in the settings.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

I see this with today's trunk build of SeaMonkey on Windows XP, too.

I get an assertion in debug:

ASSERTION: XPCWrappedNative::GetNewOrUsed called during GC: '!Scope->GetRuntime()->GetThreadRunningGC()', file c:/mozilla/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 216

Comment 2

[Adam Guthrie]

*** Bug 319526 has been marked as a duplicate of this bug. ***

Comment 3

[timeless]

Incident ID: 12823826
Stack Signature	0x020606db 97767288
Product ID	MozillaTrunk
Build ID	2005121009
Trigger Time	2005-12-10 16:07:49.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	
URL visited	
User Comments	click the composer section in the settings to display its subsections, click on a subsection in that setting and SM crashes.
Since Last Crash	38 sec
Total Uptime	1553 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x020606db
XPCWrappedNativeScope::SweepAllWrappedNativeTearOffs  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 416]
DOMGCCallback  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp, line 2202]
js_ForceGC  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsgc.c, line 1510]
nsAppStartup::Run  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/components/startup/src/nsAppStartup.cpp, line 208]
main  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1737]
WinMain  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1761]
KERNEL32.DLL + 0x1b560 (0xbff8b560)
KERNEL32.DLL + 0x1b412 (0xbff8b412)
KERNEL32.DLL + 0x19dd5 (0xbff89dd5)
  
Incident ID: 12823790
Stack Signature	MSVCRT.DLL + 0xdd6d (0x7800dd6d) 114b03e0
Product ID	MozillaTrunk
Build ID	2005121009
Trigger Time	2005-12-10 16:06:12.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	MSVCRT.DLL + (0000dd6d)
URL visited	
User Comments	Crashed while in the preferences window in the composer section
Since Last Crash	1515 sec
Total Uptime	1515 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
MSVCRT.DLL + 0xdd6d (0x7800dd6d)
MSVCRT.DLL + 0xd7a9 (0x7800d7a9)
js_FinalizeStringRT  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsstr.c, line 2715]
js_ForceGC  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsgc.c, line 1510]
nsAppStartup::Run  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/components/startup/src/nsAppStartup.cpp, line 208]
main  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1737]
WinMain  [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1761]
KERNEL32.DLL + 0x1b560 (0xbff8b560)
KERNEL32.DLL + 0x1b412 (0xbff8b412)
KERNEL32.DLL + 0x19dd5 (0xbff89dd5)

fwiw, i checked out stephend's assertion, it's bogus unfortunately, it relates to having already crashed (the cruntime library asserted about bogus free input, and when you attach a lame debugger, the app is able to limp along into the event loop and try to do another gc which asserts because the first gc that crashed didn't finish)

Comment 4

[Brendan Eich [:brendan]]

From the last comment's stack, this looks like a dup of bug 319264.

/be

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Indeed.  I updated my debug build to include Blake's changes and this crash went away.

*** This bug has been marked as a duplicate of 319264 ***