Closed Bug 454561 Opened 16 years ago Closed 16 years ago

TM: Crash when JavaScript-Debugger is enabled [@ jsd_lock ]

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1b2

People

(Reporter: tobias, Assigned: timeless)

References

Details

(Keywords: crash, fixed1.9.1)

Crash Data

Attachments

(2 files, 5 obsolete files)

WinDbg Stack Trace from Crash at SunSpider
15.60 KB, text/plain
Details
better comments, locality, context
1.85 KB, patch
brendan
: review+
Details | Diff | Splinter Review 
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910003607 Mnenhy/0.7.5.20005 SeaMonkey/2.0a1pre

File a new Bug according to Bug 453708#c16

SeaMonkey comes by default with the JavaScript-Debugger 0.9.87.4 which was enabled. almost in the Windows Zip Builds. 

Enable TraceMonkey for Content and also chrome causes a lot of crashes from jsd. I add some Crash-IDs from Bug 453708:

Windows:
bp-ce0ff3c2-7b46-11dd-9dcc-001cc45a2ce4
bp-a60dbb85-7b46-11dd-91f0-001a4bd43e5c
bp-5cb72670-7b46-11dd-b597-0013211cbf8a

bp-dae8a568-7f0f-11dd-9f81-001cc4e2bf68
bp-b3da103a-7f0f-11dd-a8c4-0013211cbf8a

Mac [@ libjsd.dylib@0x25d1 ]:
bp-1b649eee-7e90-11dd-8132-001a4bd43ef6
bp-6cd0982b-7e8c-11dd-99ef-001a4bd43ed6
bp-9fd93b70-7e8c-11dd-8538-001cc4e2bf68
bp-510d8ede-7e90-11dd-b70b-0013211cbf8a

With todays Build i got reproduceable crashes running JS-Benchmarks at SunSpider and http://dromaeo.com/ 
Also maps.google.de will crash zooming in several times, see Bug 453708.
And with todays build SM crashes when I try to join #seamonkey with both TM and JSD enabled. 

Disable the JavaScript-Debugger Add-On avoid the crashes. 

So I think it would be better to disable the JSD by default before releasing the SeaMonkey Alpha.
Flags: blocking-seamonkey2.0a1?
Emphasizing the temporariness of any such measure.
Summary: JavaScript-Debugger should be disabled by default in SeaMonkey → JavaScript-Debugger should be disabled by default in SeaMonkey2a1
http://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

please get a real stack trace. let's find the problem.
(In reply to comment #2)
> http://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
> 
> please get a real stack trace. let's find the problem.

Weeks ago, I would bet, that I would never make such things in my life. After a lot of trouble I get this one when open #seamonkey with JIT chrome and content and also JS-Debugger enabled, hope this is the wanted *real* stack trace:


Microsoft (R) Windows Debugger  Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: E:\Programme\mozilla.org\seamonkey\seamonkey.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00400000 0040c000   seamonkey.exe
ModLoad: 7c910000 7c9c6000   ntdll.dll
ModLoad: 7c800000 7c908000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 10000000 1001b000   E:\Programme\mozilla.org\seamonkey\xul.dll
ModLoad: 00280000 002e2000   E:\Programme\mozilla.org\seamonkey\xpcom_core.dll
ModLoad: 002f0000 00319000   E:\Programme\mozilla.org\seamonkey\nspr4.dll
ModLoad: 77da0000 77e4a000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e50000 77ee2000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fc0000 77fd1000   C:\WINDOWS\system32\Secur32.dll
ModLoad: 71a30000 71a3a000   C:\WINDOWS\system32\WSOCK32.dll
ModLoad: 71a10000 71a27000   C:\WINDOWS\system32\WS2_32.dll
ModLoad: 77be0000 77c38000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 71a00000 71a08000   C:\WINDOWS\system32\WS2HELP.dll
ModLoad: 76af0000 76b1e000   C:\WINDOWS\system32\WINMM.dll
ModLoad: 77ef0000 77f39000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 7e360000 7e3f1000   C:\WINDOWS\system32\USER32.dll
ModLoad: 78130000 781e1000   E:\Programme\mozilla.org\seamonkey\MOZCRT19.dll
ModLoad: 00320000 00327000   E:\Programme\mozilla.org\seamonkey\plc4.dll
ModLoad: 00330000 00337000   E:\Programme\mozilla.org\seamonkey\plds4.dll
ModLoad: 7e670000 7ee91000   C:\WINDOWS\system32\SHELL32.dll
ModLoad: 77f40000 77fb6000   C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 774b0000 775ed000   C:\WINDOWS\system32\ole32.dll
ModLoad: 77bd0000 77bd8000   C:\WINDOWS\system32\VERSION.dll
ModLoad: 00340000 003f4000   E:\Programme\mozilla.org\seamonkey\js3250.dll
(d6c.a6c): Break instruction exception - code 80000003 (first chance)
eax=00191eb4 ebx=7ffde000 ecx=00000003 edx=00000008 esi=00191f48 edi=00191eb4
eip=7c91120e esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
ntdll!DbgBreakPoint:
7c91120e cc              int     3
0:000> .sympath SRV*e:\symbols*http://symbols.mozilla.org/seamonkey
Symbol search path is: SRV*e:\symbols*http://symbols.mozilla.org/seamonkey
0:000> .symfix+ e:\symbols
0:000> .reload /f
Reloading current modules
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\xpcom_core.dll
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\nspr4.dll
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\plc4.dll
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\plds4.dll
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\js3250.dll
.*** WARNING: Unable to verify checksum for seamonkey.exe
.*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\xul.dll
.................
0:000> g
ModLoad: 76330000 7634d000   C:\WINDOWS\system32\IMM32.DLL
ModLoad: 773a0000 774a3000   C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
ModLoad: 59dd0000 59e71000   C:\WINDOWS\system32\dbghelp.dll
ModLoad: 63a40000 63a6b000   C:\Programme\GnuPG-Pack\PTD.dll
ModLoad: 770f0000 7717b000   C:\WINDOWS\system32\OLEAUT32.DLL
ModLoad: 746a0000 746ec000   C:\WINDOWS\system32\MSCTF.dll
ModLoad: 778f0000 779e4000   C:\WINDOWS\system32\SETUPAPI.dll
ModLoad: 75250000 7527e000   C:\WINDOWS\system32\msctfime.ime
ModLoad: 76f90000 7700f000   C:\WINDOWS\system32\CLBCATQ.DLL
ModLoad: 77010000 770e3000   C:\WINDOWS\system32\COMRes.dll
ModLoad: 01200000 0139e000   E:\Programme\mozilla.org\seamonkey\components\mail.dll
ModLoad: 010a0000 010bf000   E:\Programme\mozilla.org\seamonkey\components\spellchk.dll
ModLoad: 010c0000 010fb000   E:\Programme\mozilla.org\seamonkey\components\suite.dll
ModLoad: 013a0000 013a7000   E:\Programme\mozilla.org\seamonkey\xpcom.dll
ModLoad: 014b0000 014bf000   E:\Programme\mozilla.org\seamonkey\components\chrome.dll
ModLoad: 014c0000 0155a000   E:\Programme\mozilla.org\seamonkey\components\necko.dll
ModLoad: 01560000 01571000   E:\Programme\mozilla.org\seamonkey\mozz.dll
ModLoad: 719b0000 719f0000   C:\WINDOWS\system32\mswsock.dll
ModLoad: 66710000 66769000   C:\WINDOWS\system32\hnetcfg.dll
ModLoad: 719f0000 719f8000   C:\WINDOWS\System32\wshtcpip.dll
ModLoad: 017c0000 017ce000   E:\Programme\mozilla.org\seamonkey\components\xppref32.dll
ModLoad: 017d0000 017f7000   E:\Programme\mozilla.org\seamonkey\components\i18n.dll
ModLoad: 75790000 757fb000   C:\WINDOWS\system32\USP10.dll
ModLoad: 76d20000 76d39000   C:\WINDOWS\system32\iphlpapi.dll
ModLoad: 01920000 0192f000   E:\Programme\mozilla.org\seamonkey\components\jar50.dll
ModLoad: 01930000 0198b000   E:\Programme\mozilla.org\seamonkey\components\xpc3250.dll
ModLoad: 01990000 019ca000   E:\Programme\mozilla.org\seamonkey\components\gkwidget.dll
ModLoad: 019d0000 019de000   E:\Programme\mozilla.org\seamonkey\gkgfx.dll
ModLoad: 019e0000 01a6a000   E:\Programme\mozilla.org\seamonkey\thebes.dll
ModLoad: 01a70000 01a9d000   E:\Programme\mozilla.org\seamonkey\mozlcms.dll
ModLoad: 76320000 76325000   C:\WINDOWS\system32\MSIMG32.dll
ModLoad: 72f70000 72f96000   C:\WINDOWS\system32\WINSPOOL.DRV
ModLoad: 76350000 7639a000   C:\WINDOWS\system32\COMDLG32.dll
ModLoad: 5b0f0000 5b128000   C:\WINDOWS\system32\uxtheme.dll
ModLoad: 01ab0000 01abc000   E:\Programme\mozilla.org\seamonkey\components\tkitcmps.dll
ModLoad: 01ac0000 01ae3000   E:\Programme\mozilla.org\seamonkey\components\embedcomponents.dll
ModLoad: 01af0000 01b03000   E:\Programme\mozilla.org\seamonkey\components\caps.dll
ModLoad: 76ee0000 76f07000   C:\WINDOWS\system32\DNSAPI.dll
ModLoad: 76f70000 76f78000   C:\WINDOWS\System32\winrnr.dll
ModLoad: 76f20000 76f4d000   C:\WINDOWS\system32\WLDAP32.dll
ModLoad: 01b20000 01b3c000   E:\Programme\mozilla.org\seamonkey\components\rdf.dll
ModLoad: 01b40000 01b51000   E:\Programme\mozilla.org\seamonkey\components\jsd3250.dll
ModLoad: 01b60000 01b6d000   E:\Programme\mozilla.org\seamonkey\components\msgMapi.dll
ModLoad: 01b70000 01b86000   E:\Programme\mozilla.org\seamonkey\extensions\p@m\components\palmsync.dll
ModLoad: 01b90000 01b9c000   E:\Programme\mozilla.org\seamonkey\components\suitetypeaheadfind.dll
ModLoad: 01e00000 021be000   E:\Programme\mozilla.org\seamonkey\components\gklayout.dll
ModLoad: 01ba0000 01bd6000   E:\Programme\mozilla.org\seamonkey\components\imglib2.dll
ModLoad: 01be0000 01be8000   E:\Programme\mozilla.org\seamonkey\components\windowds.dll
ModLoad: 021c0000 021d2000   E:\Programme\mozilla.org\seamonkey\components\appshell.dll
ModLoad: 021e0000 024b9000   C:\WINDOWS\system32\xpsp2res.dll
ModLoad: 01bf0000 01bf8000   E:\Programme\mozilla.org\seamonkey\components\cmdlines.dll
ModLoad: 026c0000 026cf000   E:\Programme\mozilla.org\seamonkey\components\gkgfxthebes.dll
ModLoad: 027d0000 02809000   E:\Programme\mozilla.org\seamonkey\components\docshell.dll
ModLoad: 02810000 028ce000   E:\Programme\mozilla.org\seamonkey\components\uconv.dll
ModLoad: 028d0000 028df000   E:\Programme\mozilla.org\seamonkey\components\webbrwsr.dll
ModLoad: 028e0000 028e7000   E:\Programme\mozilla.org\seamonkey\components\perms.dll
ModLoad: 028f0000 028fa000   E:\Programme\mozilla.org\seamonkey\components\cookie.dll
ModLoad: 02e00000 02e0d000   E:\Programme\mozilla.org\seamonkey\components\strgcmps.dll
ModLoad: 02e10000 02e73000   E:\Programme\mozilla.org\seamonkey\sqlite3.dll
ModLoad: 02e80000 02e8a000   E:\Programme\mozilla.org\seamonkey\components\pipboot.dll
ModLoad: 02e90000 02ed7000   E:\Programme\mozilla.org\seamonkey\components\pipnss.dll
ModLoad: 02ee0000 02ef8000   E:\Programme\mozilla.org\seamonkey\smime3.dll
ModLoad: 03000000 030aa000   E:\Programme\mozilla.org\seamonkey\nss3.dll
ModLoad: 030b0000 030c4000   E:\Programme\mozilla.org\seamonkey\nssutil3.dll
ModLoad: 030d0000 030f0000   E:\Programme\mozilla.org\seamonkey\ssl3.dll
ModLoad: 032f0000 03315000   E:\Programme\mozilla.org\seamonkey\softokn3.dll
ModLoad: 03320000 03338000   E:\Programme\mozilla.org\seamonkey\nssdbm3.dll
ModLoad: 03340000 03379000   E:\Programme\mozilla.org\seamonkey\freebl3.dll
ModLoad: 03380000 033c9000   E:\Programme\mozilla.org\seamonkey\nssckbi.dll
ModLoad: 03500000 03536000   E:\Programme\mozilla.org\seamonkey\components\gkparser.dll
ModLoad: 033d0000 033da000   E:\Programme\mozilla.org\seamonkey\components\chardet.dll
ModLoad: 033e0000 033e8000   E:\Programme\mozilla.org\seamonkey\components\txmgr.dll
ModLoad: 033f0000 033fa000   E:\Programme\mozilla.org\seamonkey\components\intlapp.dll
ModLoad: 036e0000 036fb000   E:\Programme\mozilla.org\seamonkey\components\appcomps.dll
ModLoad: 03c30000 03c4b000   E:\Programme\mozilla.org\seamonkey\components\mork.dll
ModLoad: 03c50000 03c5a000   E:\Programme\mozilla.org\seamonkey\components\satchel.dll
ModLoad: 03c60000 03c6a000   E:\Programme\mozilla.org\seamonkey\components\tkautoc.dll
ModLoad: 77660000 77681000   C:\WINDOWS\system32\NTMARTA.DLL
ModLoad: 71b70000 71b83000   C:\WINDOWS\system32\SAMLIB.dll
ModLoad: 76f80000 76f86000   C:\WINDOWS\system32\rasadhlp.dll
ModLoad: 042f0000 042ff000   E:\Programme\mozilla.org\seamonkey\components\composer.dll
(d6c.a6c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=0000041c edx=01047b22 esi=01047b12 edi=00000000
eip=7c92b1fa esp=0012f820 ebp=0012f894 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
ntdll!RtlpWaitForCriticalSection+0x8c:
7c92b1fa ff4010          inc     dword ptr [eax+10h]  ds:0023:00000010=????????
0:000> kp
ChildEBP RetAddr  
0012f894 7c911046 ntdll!RtlpWaitForCriticalSection+0x8c
0012f89c 00305f37 ntdll!RtlEnterCriticalSection+0x46
*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\components\jsd3250.dll
0012f8ac 01b42079 nspr4!PR_Lock(struct PRLock * lock = 0x01b43881)+0x17 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\nsprpub\pr\src\threads\combined\prulock.c @ 240]
0012f8bc 01b4360f jsd3250!jsd_Lock(struct JSDStaticLock * lock = 0x01b43881)+0x20 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_lock.c @ 146]
0012f8ec 01b43881 jsd3250!_callHook(struct JSDContext * jsdc = 0x047aa800, struct JSContext * cx = 0x011469a0, struct JSStackFrame * fp = 0x04566098, int before = 0, unsigned int type = 3, <function> * hook = 0x03f48e71, void * hookData = 0x00000016)+0x91 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_step.c @ 139]
0012f924 00378bbb jsd3250!jsd_FunctionCallHook(struct JSContext * cx = 0x011469a0, struct JSStackFrame * fp = 0x04566098, int before = 0, int * ok = 0x0012f9cc, void * closure = 0x047aa800)+0x4f [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_step.c @ 287]
0012fa14 0036dd36 js3250!js_Interpret(struct JSContext * cx = 0x011469a0)+0xa5fb [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\src\jsinterp.cpp @ 2962]
0012fa9c 003473b3 js3250!js_Execute(struct JSContext * cx = 0x00000000, struct JSObject * chain = 0x03f0b800, struct JSScript * script = 0x00cad1a0, struct JSStackFrame * down = 0x00000000, unsigned int flags = 0, long * result = 0x00000000)+0x1d6 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\src\jsinterp.cpp @ 1553]
*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\components\gklayout.dll
0012fac8 01fb35a6 js3250!JS_EvaluateUCScriptForPrincipals(struct JSContext * cx = 0x011469a0, struct JSObject * obj = 0x03f0b800, struct JSPrincipals * principals = 0x00c7d884, unsigned short * chars = 0x03fb6fa0, unsigned int length = 0xa, char * filename = 0x00ca6d98 "chrome://chatzilla/content/static.js", unsigned int lineno = 0x567, long * rval = 0x00000000)+0x83 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\src\jsapi.cpp @ 5019]
0012fb3c 01fadb1d gklayout!nsJSContext::EvaluateString(class nsAString_internal * aScript = 0x0012fb70, void * aScopeObject = 0x03f0b800, class nsIPrincipal * aPrincipal = 0x00c7d880, char * aURL = 0x00ca6d98 "chrome://chatzilla/content/static.js", unsigned int aLineNo = 0x567, unsigned int aVersion = 0, class nsAString_internal * aRetValue = 0x00000000, int * aIsUndefined = 0x0012fb7c)+0x194 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\dom\src\base\nsjsenvironment.cpp @ 1572]
0012fc14 01faddc0 gklayout!nsGlobalWindow::RunTimeout(struct nsTimeout * aTimeout = 0x00ca11c0)+0x225 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\dom\src\base\nsglobalwindow.cpp @ 7694]
0012fc20 002ab926 gklayout!nsGlobalWindow::TimerCallback(class nsITimer * aTimer = 0x00285f2f, void * aClosure = 0x00000001)+0x11 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\dom\src\base\nsglobalwindow.cpp @ 8048]
0012fc38 002aba9c xpcom_core!nsTimerImpl::Fire(void)+0x94 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\xpcom\threads\nstimerimpl.cpp @ 420]
0012fc40 002ac21a xpcom_core!nsTimerEvent::Run(void)+0x1b [e:\builds\slave\comm-central-win32-nightly\build\mozilla\xpcom\threads\nstimerimpl.cpp @ 514]
0012fc60 00285f2f xpcom_core!nsThread::ProcessNextEvent(int mayWait = 1, int * result = 0x0012fc7c)+0xc3 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\xpcom\threads\nsthread.cpp @ 511]
*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\components\gkwidget.dll
0012fc74 019aac15 xpcom_core!NS_ProcessNextEvent_P(class nsIThread * thread = 0x00000001, int mayWait = 1)+0x20 [e:\builds\slave\comm-central-win32-nightly\build\objdir\mozilla\xpcom\build\nsthreadutils.cpp @ 227]
*** WARNING: Unable to verify checksum for E:\Programme\mozilla.org\seamonkey\components\tkitcmps.dll
0012fc88 01ab164f gkwidget!nsBaseAppShell::Run(void)+0x2a [e:\builds\slave\comm-central-win32-nightly\build\mozilla\widget\src\xpwidgets\nsbaseappshell.cpp @ 170]
0012fc94 10006e4c tkitcmps!nsAppStartup::Run(void)+0x1e [e:\builds\slave\comm-central-win32-nightly\build\mozilla\toolkit\components\startup\src\nsappstartup.cpp @ 183]
0012ff1c 0040125d xul!XRE_main(int argc = 1, char ** argv = 0x00b1c088, struct nsXREAppData * aAppData = 0x00b13240)+0x143c [e:\builds\slave\comm-central-win32-nightly\build\mozilla\toolkit\xre\nsapprunner.cpp @ 3224]
0012ff4c 00401360 seamonkey!NS_internal_main(int argc = 1, char ** argv = 0x00b1c088)+0xc1 [e:\builds\slave\comm-central-win32-nightly\build\suite\app\nssuiteapp.cpp @ 104]
So, this 1) happens only when TraceMonkey is being enabled, which it isn't by default, and 2) in jsd, not in venkman code itself?

1) is not on by default, so I don't see why we should care too much about that for alpha, it's known to be experimental for now
2) means it happens in core code that is always in the app and would be triggered by FireBug/FireChrome or whatever it is that hooks into jsd as well there, so this is an issue that doesn't just affect SeaMonkey and venkman.

Additionally, could you try with a build from September 10 or later code? We had another TraceMonkey merge that should have fixed a number of known bugs there.
Assignee: build-config → general
Component: Build Config → JavaScript Engine
Flags: blocking-seamonkey2.0a1?
Product: SeaMonkey → Core
QA Contact: build-config → general
Add another WinDbg Stack Trace from crash running SunSpider Benchmark, TM and JSD enabled. 

Add the first Lines here too:
0012f07c 01b4360f jsd3250!jsd_Lock(struct JSDStaticLock * lock = 0x01b43881)+0xe [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_lock.c @ 139]
0012f0ac 01b43881 jsd3250!_callHook(struct JSDContext * jsdc = 0x0483e020, struct JSContext * cx = 0x02fda480, struct JSStackFrame * fp = 0x03f834a0, int before = 0, unsigned int type = 3, <function> * hook = 0x00000003, void * hookData = 0x00000003)+0x91 [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_step.c @ 139]
0012f0e4 00378bbb jsd3250!jsd_FunctionCallHook(struct JSContext * cx = 0x02fda480, struct JSStackFrame * fp = 0x03f834a0, int before = 0, int * ok = 0x0012f18c, void * closure = 0x0483e020)+0x4f [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\jsd\jsd_step.c @ 287]
0012f1d4 0036dd36 js3250!js_Interpret(struct JSContext * cx = 0x02fda480)+0xa5fb [e:\builds\slave\comm-central-win32-nightly\build\mozilla\js\src\jsinterp.cpp @ 2962]
Summary: JavaScript-Debugger should be disabled by default in SeaMonkey2a1 → TM: Crash when JavaScript-Debugger is enabled [ @ jsd_lock ]
jsd3250!jsd_Lock(struct JSDStaticLock * lock = 0x01b43881)+0x20
[jsd_lock.c @ 146]
nspr4!PR_Lock(struct PRLock * lock = 0x01b43881)+0x17 [combined\prulock.c @ 240]
239     _PR_MD_LOCK(&lock->ilock);
where _PR_MD_LOCK means: EnterCriticalSection(&((lock)->mutex))

ntdll!RtlEnterCriticalSection+0x46
ntdll!RtlpWaitForCriticalSection+0x8c
inc     dword ptr [eax+10h]  ds:0023:00000010=????????

this means that the lock was a null pointer (mutex is +10h from the start of the lock structure), which in turn means that lock->ilock = 0

but this doesn't make sense, because the lock in question seems fairly well guarded, and we intentionally leak all of them :) [i.e., there's no code path to delete any of them or null them out].

please find me on irc, one approach is to just share your .dmp w/ me:
.dump /maipwd /u /ba /c "comment" file

and the other is that i talk you through things. (please don't expect me to build, my envs aren't really up for that)
tracer should be off if debugger is on.
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b1
Summary: TM: Crash when JavaScript-Debugger is enabled [ @ jsd_lock ] → disable tracing when JavaScript-Debugger is enabled [ @ jsd_lock ]
Indeed, on Mac and Linux jumpTable can only point to one of recordingJumpTable and interruptJumpTable.

Perhaps there's a Windows bug due to Windows still using a switch-loop?

/be
Target Milestone: mozilla1.9.1b1 → mozilla1.9.1b2
Flags: blocking1.9.1+
Blocks: 461054
I can surely reproduce this bug on Linux. We have website (it's corporate, so i can't post a link here) and if i have JIT and Venkman enabled, it crashes. Disabling Venkman or JIT resolves problem.
Here is some debug info:

[New Thread 0xb1efcb90 (LWP 16813)]
[Thread 0xb549eb90 (LWP 16812) exited]
Document http://skyprovision/login.jsp loaded successfully
[New Thread 0xb549eb90 (LWP 16814)]
[New Thread 0xb14fbb90 (LWP 16815)]
[Thread 0xb1efcb90 (LWP 16813) exited]
[Thread 0xb549eb90 (LWP 16814) exited]
Error loading URL http://skyprovision/updateCookie.jsp?loginURL=j_security_check : 804b0002 (NS_BINDING_ABORTED)
Error loading URL http://skyprovision/j_security_check : 804b0002 (NS_BINDING_ABORTED)

Program received signal SIGSEGV, Segmentation fault.
0x00ad4bcf in jsd_Lock () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libjsd.so

(gdb) bt
#0  0x00ad4bcf in jsd_Lock () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libjsd.so
#1  0x00ad68f6 in _callHook () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libjsd.so
#2  0x00ad6c8e in jsd_FunctionCallHook () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libjsd.so
#3  0x00148702 in js_Interpret () from ./libmozjs.so
#4  0x0015a5d3 in js_Execute () from ./libmozjs.so
#5  0x001208cd in JS_EvaluateUCScriptForPrincipals () from ./libmozjs.so
#6  0x03a88c3e in nsJSContext::EvaluateString () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libgklayout.so
#7  0x039849ed in nsScriptLoader::EvaluateScript () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libgklayout.so
#8  0x03984aeb in nsScriptLoader::ProcessRequest () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libgklayout.so
#9  0x03984bab in nsScriptLoader::ProcessPendingRequests ()
   from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libgklayout.so
#10 0x03984ca1 in nsScriptLoader::OnStreamComplete () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libgklayout.so
#11 0x021a6488 in nsStreamLoader::OnStopRequest () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libnecko.so
#12 0x021a61f6 in nsStreamListenerTee::OnStopRequest () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libnecko.so
#13 0x021f7dc6 in nsHttpChannel::OnStopRequest () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libnecko.so
#14 0x02190736 in nsInputStreamPump::OnStateStop () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libnecko.so
#15 0x02190a79 in nsInputStreamPump::OnInputStreamReady () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libnecko.so
#16 0x00240770 in nsInputStreamReadyEvent::Run () from ./libxpcom_core.so
#17 0x00253bb8 in nsThread::ProcessNextEvent () from ./libxpcom_core.so
#18 0x002240eb in NS_ProcessNextEvent_P () from ./libxpcom_core.so
#19 0x09557265 in nsBaseAppShell::Run () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libwidget_gtk2.so
#20 0x00b44248 in nsAppStartup::Run () from /home/misak/workspace/src/suite-opt/mozilla/dist/bin/components/libtoolkitcomps.so
#21 0x001df54d in XRE_main () from ./libxul.so
#22 0x080491a5 in main ()
please don't bother to spam this bug w/ more stacks. i was just going to debug it.
Assignee: general → graydon
I have a crash that looks similar -- but not identical -- to this bug. It's based on the decompiler crashing when running sunspider with the JIT and firebug both turned on. I've isolated the bug I'm looking at down to the range of revisions between 8062a7d3dba6 and 63ba972636ad, which was the introduction of upvars on Aug 21.

Diagnosing this with Brendan presently. It appears in this case to relate to eval scripts that use upvars not propagating their enclosing function to the debugger. But it makes no sense that this might relate to the disabled-ness of the JIT (since it's supposed to be disabled anyways). Investigating further.

Meanwhile, here is a quick diagnostic patch that just turns off the use of JSOP_GETUPVAR: if your bug goes away when this patch is applied, we are looking at the same bug. If not, I should open a second bug.

diff -r 3c7a9135330b js/src/jsemit.cpp
--- a/js/src/jsemit.cpp	Fri Oct 24 14:01:17 2008 -0700
+++ b/js/src/jsemit.cpp	Fri Oct 24 16:56:10 2008 -0700
@@ -1875,7 +1875,7 @@
         if (caller) {
             JS_ASSERT(tc->flags & TCF_COMPILE_N_GO);
             JS_ASSERT(caller->script);
-            if (!caller->fun || caller->varobj != tc->u.scopeChain)
+            if (JS_TRUE || !caller->fun || caller->varobj != tc->u.scopeChain)
                 return JS_TRUE;
 
             /*
As best I can tell, this patch shuts down existing JIT activity and prohibits further JIT activity when the debug service is active. It makes no attempt to "re-enable" the JIT when the debug service "turns off" either; this is conservative. 

The patch alone does not free us from crashes, however; there still seems to be some misbehavior specifically inside the Tofte testcase, when the JIT is "enabled". But it might fix the original reporter's case. Not sure. I'm still crashing in a different place, related to JSOP_GETUPVAR decompilation.

What's most mysterious to me about this is that the JIT is never being entered. A breakpoint on js_ExecuteTree no longer fires, because of this patch; yet I still get a crash on Tofte when (and only when) the jit.content preference is set to true.

As before, fully disabling the emitting of JSOP_GETUPVAR causes the entire test scenario to work. Both with and without this patch. Though this patch *does* accomplish the general "shut the JIT off when debug is active" stated purpose of the bug.

Further advice, help testing or figuring out what on earth is going on would be appreciated.
ok with a debug build (thanks to bernd) at MozCamp'08... it looks like hookData = 0xdadadada [ JS_FREE_PATTERN (deallocated JSArena - GC()d) ]

-		(JSInlineFrame *) fp	0x07d3bd6c {frame={...} callerRegs={...} mark=0x07d3bd6c ...}	JSInlineFrame *
+		frame	{regs=0x0012f384 slots=0x07d3bddc callobj=0x078b08c0 ...}	JSStackFrame
+		callerRegs	{pc=0x082e15f5 ":" sp=0x07d3bd6c }	JSFrameRegs
		mark	0x07d3bd6c	void *
		hookData	0xdadadada	void *
		callerVersion	0xdadadada	JSVersion

so, neither hookData nor callerVersion are ok.

                if (hookData) {
                    hook = cx->debugHooks->callHook;
                    if (hook) {
                        hook(cx, fp, JS_FALSE, &status, hookData);


jsd_FunctionCallHook(JSContext *cx, JSStackFrame *fp, JSBool before,
    jsdc = (JSDContext*) closure;
    hook     = jsdc->functionHook;

jsdc = 0xdadadada from the caller, and we're going to die.

I didn't have time to track down what wasn't properly filling in those fields (I had to catch my flight - which wasn't really in any hurry to take off, 60+mins w/o A/C; 80mins delay).
Hah. Mystery solved. I was incorrect in believing that it doesn't crash with the JIT off. It does. Tracking two bugs at once here. Untangling: my tofte-upvar fault is over in bug 461801 now. Let's keep this one focused on "turn off the JIT when debugger is on".

timeless: is your comment 14 here using the patch I proposed above (attachment #2 [details] [diff] [review]) or are you just reproducing the original fault in general? I do not know how to further reproduce this bug *without* the approach I was previously using.
just reproducing the original.
Ok. I was assuming this related to firebug, but I actually can't reproduce with it. If I use venkman instead, I can reproduce by turning on the debugger and vigorously exercising maps.google.de.

If I apply attachment #2 [details] [diff] [review] above, I cannot produce a crash this way. So I think it fixes the bug. I'm trying a minimal variant of it now, since I'm a bit worried about the cost of the proposed technique.
Attached patch minimal solution to the bug (obsolete) — — Splinter Review 
This patch appears to solve the bug -- at least removes my ability to reproduce it on maps.google.de -- with minimal intrusion: it just stops making *new* JIT-based JS contexts when the debugger hooks are present, rather than chasing through the existing contexts trying to shut them down. I'm not sure whether I like this one or the former one better -- the former is more thorough but this is much less invasive -- so I'll leave it not-obsolete, in case we want to go back and do it instead. 

I worry, though, that if we do this seamonkey will simply not get the JIT by default. Does it really ship with the debugger active?

I'm also not sure if the r? request is correct here, or whether I need sr. The nsJSEnvironment file may be someone else's turf, not just js-engine. Suggestion?
Attachment #345018 - Flags: review?(brendan)
Attachment #345018 - Flags: review?(brendan) → review?(mrbkap)
Comment on attachment 345018 [details] [diff] [review]
minimal solution to the bug

Looks good.
Attachment #345018 - Flags: superreview+
Attachment #345018 - Flags: review?(mrbkap)
Attachment #345018 - Flags: review+
Comment on attachment 345018 [details] [diff] [review]
minimal solution to the bug

The JS_Set*Hook APIs take null to mean "Clear" -- can we hook into those to re-enable later? Followup bug, no need for patch to grow here.

/be
Pushed in revision b0d41235146a. 

Brendan: since the patch pushed is predicated on the non-nullness of the debug hook, it actually reverts to constructing JSOPTION_JIT JSContexts when the debug hook is cleared. I've confirmed that if you disable firebug, the JIT re-engages.

I'm still a bit worried about seamonkey here. Is the debugger on by default? If so we're going to be "non-JIT" by default there, to match. I don't see much else we could do though, considering the two don't play nice together.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I think the debug hooks are already enabled as soon as SeaMonkey has been launched. Maybe something needs to change in Venkman, someone who knows more about Venkman than I do needs to comment on that.
Attachment #345018 - Flags: review-
Comment on attachment 345018 [details] [diff] [review]
minimal solution to the bug

graydon: your ifdef is illegal. there are spidermonkey embedders w/ their own jsdebuggers and they shouldn't crash either....
Comment on attachment 344792 [details] [diff] [review]
patch that disables the JIT when the debug service is active

something like this seems to be more correct as you should let those other js api consumers easily disable jit, if not automatically do so in the presence of a jsapi debugger.
for people curious about whether venkman really turns the debugger on by default, it does:

http://mxr.mozilla.org/comm-central/source/mozilla/extensions/venkman/js/venkman-service.js?mark=565-576,570#527
so... the code in question really pretends to create JSInlineFrames, but it really doesn't properly initialize them. this is purely a bug in spidermonkey.

If the code doesn't want the debugger to run, it'd be sufficient to *properly* fill in the JSInlineFrame.hookData field w/ null.

Someone w/ a compiler should be able to verify that such a variant (basically omitting the second half of this patch) fixes the crash.
Comment on attachment 345073 [details] [diff] [review]
conceptual changes - not tested because i'm on a mac-ppc which can't possibly build anything

Timeless, good catch -- I couldn't tell from your comments, is this a complete fix for the symptom?

Realize it's a "conceptual" patch, but it's also a patch that is close to being ready for checkin, so I'm reviewing.

> #ifdef DEBUG
>     newifp->frame.pcDisabledSave = 0;
> #endif

Blank line before comment-line, please.

>+    /* debugger call hook data */

Generally we want sentences for comments that take up one or more lines (capitalized, full stop).

>+    newifp->hookData = 0;
>+    /* dynamic version of calling script */
>+    newifp->callerVersion = cx->version;

Ditto on both nits.

We can't JIT a non-default version script AFAICS. This could be problematic if version has runtime significance (it has in the past, although we try to make it compile-time where possible). Could use a separate bug on this item. Using cx->version is ok for now.

>+    JSInterpreterHook hook;
>+    /* Init these now in case we goto out before first hook call. */

Nice sentence-comment, but put the hook decl below it and initialize in the decl:

>+    hook = cx->debugHooks->callHook;
>+    newifp->hookData = hook(cx, &newifp->frame, JS_TRUE, 0, cx->debugHooks->callHookData);

And null-test hook before calling it and assigning to hookData, with an else clause that nulls hookData -- just as the code at inline_call: in jsinterp.cpp does.

/be
Assignee: graydon → timeless
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: disable tracing when JavaScript-Debugger is enabled [ @ jsd_lock ] → TM: Crash when JavaScript-Debugger is enabled [ @ jsd_lock ]
Attached patch more correct patch (obsolete) — — Splinter Review 
OK, Fallen tested attachment 345073 [details] [diff] [review] and it needed a cast for JSVersion. Other than crashing in some accessible code (unrelated, bug filed, patched, fixed), Venkman worked. So I believe changes like this should be the complete correct fix.

this version includes a cast there and more comments.

brendan's comment indicated to me that i grabbed the wrong version field - so I'm now pulling the one from script which I think is more correct. Filing a follow-on bug for considering versions can be done later.

I don't have a build environment handy, I will try to get a try server build for this (I will need to find my credentials and figure out how to use it), so this patch as with the previous might not compile, but I think it will.
Attachment #344792 - Attachment is obsolete: true
Attachment #345018 - Attachment is obsolete: true
Attachment #345073 - Attachment is obsolete: true
Attachment #345257 - Flags: review?(brendan)
Depends on: 462030
Comment on attachment 345257 [details] [diff] [review]
more correct patch

>comparing with http://hg.mozilla.org/mozilla-central
>searching for changes
>changeset:   21044:b377d093329a
>parent:      20981:b0d41235146a
>user:        timeless@mozdev.org
>date:        Wed Oct 29 10:15:48 2008 +0100
>summary:     Backed out changeset b0d41235146a
>
>diff --git a/dom/src/base/nsJSEnvironment.cpp b/dom/src/base/nsJSEnvironment.cpp
>--- a/dom/src/base/nsJSEnvironment.cpp
>+++ b/dom/src/base/nsJSEnvironment.cpp
>@@ -1172,12 +1172,6 @@ nsJSContext::JSOptionChangedCallback(con
>   PRBool useJIT = nsContentUtils::GetBoolPref(chromeWindow ?
>                                               js_jit_chrome_str :
>                                               js_jit_content_str);
>-
>-#ifdef MOZ_JSDEBUGGER
>-  if (context->mContext->debugHooks->debuggerHandler)
>-    useJIT = PR_FALSE;
>-#endif
>-
>   if (useJIT)
>     newDefaultJSOptions |= JSOPTION_JIT;
>   else
>

Let's not back this out in this bug's patch.

>+    /* We need to fill in the other members of JSInternalFrame to support
>+     * debuggers. We're doing this before js_GetCallObject because in order
>+     * for that to fail (which is handled), it could try to enter a
>+     * debugger hook. */

Please use standard major comment style here (as nearby comments do). We are allowing Harbison&Steele style comments in jstracer.cpp for now (to avoid breaking too much of Andreas's style-brain ;-), but you are here introducing yet a third major-comment style.

>+    newifp->hookData = 0;
>+    newifp->callerVersion = (JSVersion) script->version;

Good fix, I should have been explicit.

>+    /* If there's a callHook, we need to properly fill in hookData.
>+     * We don't need to set hookData to null here otherwise because
>+     * it was initialized to null before calling js_GetCallObject. */

Nit again.

>+    JSInterpreterHook hook = cx->debugHooks->callHook;
>+    if (hook) {
>+        newifp->hookData = hook(cx, &newifp->frame, JS_TRUE, 0,
>+                                cx->debugHooks->callHookData);
>     }

You forgot the else clause that nulls hookData.

/be
I can confirm that timeless' 2nd patch fixes the maps.google.de crash under the debugger, which I can still reproduce here. I've not been able to reproduce a dromaeo crash. But I'm inclined to think that he's right and disabling the JIT entirely due to the presence of the debugger was overkill. It looks like the JIT can handle it ok on its own, simply by aborting traces containing JSOP_TRAP. Neat!
I suggest landing the patch and then add the following features in a separate bug:

- Flush the JIT cash every time a JSOP_TRAP is added or removed.

- Compile JSOP_TRAP into a LIR_x with a new exitType (DEBUGGER_EXIT) and end the loop (endLoop) at the JSOP_TRAP. This will force native code to exit whenever the location of JSOP_TRAP is hit.
Cash for Your Trash - Fats waller ;-)

This sounds like a plan!

/be
Comment on attachment 345257 [details] [diff] [review]
more correct patch

>+    newifp->hookData = 0;

We use NULL not 0 (you know this), but I'd rather you just use the else clause as noted in review.

/be
Attached patch matching style (obsolete) — — Splinter Review 

        Attachment #345257 -
        Attachment is obsolete: true

        Attachment #345596 -
        Flags: review?(brendan)

        Attachment #345257 -
        Flags: review?(brendan)

    
    

    
  
Comment on attachment 345596 [details] [diff] [review]
matching style

>diff --git a/js/src/jstracer.cpp b/js/src/jstracer.cpp
>--- a/js/src/jstracer.cpp
>+++ b/js/src/jstracer.cpp
>@@ -2395,2 +2395,11 @@ js_SynthesizeFrame(JSContext* cx, const 
> 
>+    /*
>+     * We need to fill in the other members of JSInternalFrame to support
>+     * debuggers. We're doing this before js_GetCallObject because in order
>+     * for that to fail (which is handled), it could try to enter a
>+     * debugger hook.
>+     */
>+    newifp->hookData = NULL;

Is this an mq patch? It seems incremental on the last one, but the last one didn't land yet (or you didn't give an hgweb link in the bug for its landing).

Again, don't null twice. There is no risk of call-out; if there were, it would bite anything, since the frame is not fully initialized until very near the bottom of js_SynthesizeFrame. Null once in the else clause...

>+    newifp->callerVersion = (JSVersion) script->version;
>+
>     cx->fp->regs = &newifp->callerRegs;
>@@ -2403,2 +2412,16 @@ js_SynthesizeFrame(JSContext* cx, const 
> 
>+    /*
>+     * If there's a callHook, we need to properly fill in hookData.
>+     * Although we set hookData to null before calling js_GetCallObject,
>+     * I'm setting it to null again anyway as there's some very remote
>+     * chance that under js_GetCallObject it got changed.
>+     */
>+    JSInterpreterHook hook = cx->debugHooks->callHook;
>+    if (hook) {
>+        newifp->hookData = hook(cx, &newifp->frame, JS_TRUE, 0,
>+                                cx->debugHooks->callHookData);
>+    } else {
>+        newifp->hookData = NULL;

... here.

/be

        Attachment #345596 -
        Flags: review?(brendan) → review-

    
    

    
  


  
graydon verified it still works.

        Attachment #345596 -
        Attachment is obsolete: true

        Attachment #345634 -
        Flags: review?(brendan)

    
    

    
  
Comment on attachment 345634 [details] [diff] [review]
better comments, locality, context

>+         * Set hookData to NULL because the failure case for js_GetCallObject

Nit: comments use "null" and avoid shouting ;-).

r=me with that picked. Thanks for patching this and keeping after it.

/be

        Attachment #345634 -
        Flags: review?(brendan) → review+

    
    

    
  
fixed in changeset 9ddc91081435
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Flags: in-litmus-

    
  
Severity: normal → critical
Keywords: crash
Summary: TM: Crash when JavaScript-Debugger is enabled [ @ jsd_lock ] → TM: Crash when JavaScript-Debugger is enabled [@ jsd_lock ]
Crash Signature: [@ jsd_lock ]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: