Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 700302 - trunk crash in strlen coming from jsds_FilterHook (via nsDependentCString::nsDependentCString?)
: trunk crash in strlen coming from jsds_FilterHook (via nsDependentCString::ns...
: crash, verified-beta
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical with 1 vote (vote)
: mozilla11
Assigned To: Steve Fink [:sfink] [:s:]
: Jason Orendorff [:jorendorff]
: 700311 700564 701121 701276 702650 (view as bug list)
Depends on: 711953
Blocks: 136292
  Show dependency treegraph
Reported: 2011-11-07 07:25 PST by Robert Kaiser
Modified: 2013-12-27 14:31 PST (History)
21 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Handle null script filenames (810 bytes, patch)
2011-11-11 11:32 PST, Steve Fink [:sfink] [:s:]
no flags Details | Diff | Splinter Review
Handle null script filenames (886 bytes, patch)
2011-11-11 11:38 PST, Steve Fink [:sfink] [:s:]
sphink: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Robert Kaiser 2011-11-07 07:25:50 PST
This bug was filed from the Socorro interface and is 
report bp-54edbd3d-1a2e-4665-ada3-697052111106 .

This crash might be related to bug 631113 but I couldn't see nsJSContext::EvaluateString in the stacks, so I'm fining a new one.

The report linked above seems to be the signature seen on 64bit, more reports with that are at|%20jsds_FilterHook%28JSDContext*%2C%20JSDThreadState*%29 - the 32bit variant seems to be e.g. bp-45e0579d-b571-41fa-8c60-c7cd02111107 and|%20nsDependentCString%3A%3AnsDependentCString%28char%20const*%29 lists more of those.

As JSD is involved, Firebug is installed in all the reports I looked at.

Top stack frames from the 64bit variant:
0 	msvcr90.dll 	strlen 	f:\\dd\\vctools\\crt_bld\\SELF_64_amd64\\crt\\src\\amd64\\strlen.asm:70
1 	xul.dll 	jsds_FilterHook 	js/jsd/jsd_xpc.cpp:381
2 	mozutils.dll 	je_malloc 	memory/jemalloc/jemalloc.c:6220
3 	nspr4.dll 	MD_CURRENT_THREAD 	nsprpub/pr/src/md/windows/w95thred.c:308
4 	xul.dll 	jsdValue::jsdValue 	js/jsd/jsd_xpc.cpp:2157
5 	nspr4.dll 	PR_Unlock 	nsprpub/pr/src/threads/combined/prulock.c:347
6 	xul.dll 	jsdValue::FromPtr 	js/jsd/jsd_xpc.cpp:2147
7 	xul.dll 	jsds_ExecutionHookProc 	js/jsd/jsd_xpc.cpp:684
8 	xul.dll 	jsd_NewThreadState 	js/jsd/jsd_stak.c:169
9 	xul.dll 	xul.dll@0x8d6d63 	
10 	xul.dll 	xul.dll@0x8d6d63 	
11 	xul.dll 	xul.dll@0x8d6d63 	
12 	xul.dll 	jsd_CallExecutionHook 	js/jsd/jsd_hook.c:177
13 	xul.dll 	jsd_ThrowHandler 	js/jsd/jsd_hook.c:149
14 	xul.dll 	xul.dll@0x8d6d63 	
15 	xul.dll 	js::Interpret 	js/src/jsinterp.cpp:5950
43 	xul.dll 	js::Invoke 	js/src/jsinterp.cpp:679
44 	xul.dll 	nsCxPusher::~nsCxPusher 	content/base/src/nsContentUtils.cpp:2508
45 	xul.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5168
46 	xul.dll 	nsXBLProtoImplAnonymousMethod::Execute 	content/xbl/src/nsXBLProtoImplMethod.cpp:367
(those frames in the 40s are just included to see that in both 64bit and 32bit we're going from XBL into JS)

Top frames on 32bit:
0 	msvcr80.dll 	strlen 	F:\\dd\\vctools\\crt_bld\\SELF_X86\\crt\\src\\intel\\strlen.asm:81
1 	xul.dll 	nsDependentCString::nsDependentCString 	obj-firefox/dist/include/nsTDependentString.h:90
2 	xul.dll 	jsds_FilterHook 	js/jsd/jsd_xpc.cpp:381
3 	xul.dll 	jsds_ExecutionHookProc 	js/jsd/jsd_xpc.cpp:684
4 	xul.dll 	jsd_CallExecutionHook 	js/jsd/jsd_hook.c:177
5 	xul.dll 	jsd_ThrowHandler 	js/jsd/jsd_hook.c:149
6 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:5950
7 	mozjs.dll 	JSScript::makeTypes 	js/src/jsinfer.cpp:5443
8 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:584
9 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:647
10 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:679
11 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5168
12 	xul.dll 	nsXBLProtoImplAnonymousMethod::Execute 	content/xbl/src/nsXBLProtoImplMethod.cpp:367

While the 32bit signature seems to be present in older versions as well, both have been not happening on trunk in the last few days before, but suddenly came to existence with the 10.0a1 Nightly builds from 2001-11-05 are have been #2 (64bit) and #5 (32bit) topcrashes on 10 yesterday.
Comment 1 Robert Kaiser 2011-11-07 07:51:59 PST
It looks like bp-f2aaa844-2a19-4abd-ba64-1d16f2111106 is a Linux example, see for more Linux reports with the jsds_FilterHook signature.
Comment 2 Marcia Knous [:marcia - use ni] 2011-11-07 09:52:48 PST
I see crashes in Windows that started using the 2011110500 build. I will get the pushlog regression range.
Comment 3 Marcia Knous [:marcia - use ni] 2011-11-07 09:57:10 PST is the pushlog regression range according to what it is in crash stats.

Some of the comments mention that they are crashing every time they close the browser.
Comment 4 Robert Kaiser 2011-11-07 11:07:36 PST
(In reply to Marcia Knous [:marcia] from comment #2)
> I see crashes in Windows that started using the 2011110500 build.

Oh, I filed this for the Windows reports anyhow originally, I just forgot to correct the fields from my platform to that... ;-)
Comment 5 Mathieu Marquer 2011-11-07 11:26:59 PST
Occurs to me (Ubuntu 11.10 64 bits), after most of times I close the browser Firefox won't launch again (keeps crashing) unless I extract the .tar.bz2 nightly archive into firefox directory again.
Comment 6 Marcia Knous [:marcia - use ni] 2011-11-07 12:55:47 PST
Adding the Mac signature - the Mac spike started on the trunk the same time as the Windows crash and seems to be only happening on 10.7.
Comment 7 Bob Clary [:bc:] 2011-11-08 02:13:24 PST
I hit a crash on restart [@ strlen | jsds_FilterHook ] on Mac OS X 10.5 after my session hit > 1G memory usage and I couldn't shutdown and was forced to kill the process. On restarting I got in a crash on restart loop that only terminated when I removed the most recent window (a bugzilla query that had not completed).

Comment 8 Bob Clary [:bc:] 2011-11-08 16:04:22 PST
Got into another crash+crash on restart cycle on Mac OS X 10.5. Was probably related to Firebug 1.9.0a5 which I have disabled.
Comment 9 Marcia Knous [:marcia - use ni] 2011-11-09 13:20:33 PST
*** Bug 701121 has been marked as a duplicate of this bug. ***
Comment 10 James Long (:jlongster) 2011-11-09 13:53:34 PST
I'm the one who filed bug 701121, and I got the crash on restart cycle too. I have Firebug 1.8.4 installed (I disabled addon compatibility), so that might be related.
Comment 11 timeless 2011-11-11 11:22:58 PST
from the jsd_xpc side, the code expects a null but uses a Dependent string which objects.

however, this code worked fine for nearly 3 years, so js seems to have changed something.
Comment 12 Steve Fink [:sfink] [:s:] 2011-11-11 11:32:00 PST
Created attachment 573866 [details] [diff] [review]
Handle null script filenames

timeless popped up on IRC because he ran into this, and gave the simple solution. Apparently, the JS engine is now returning null from JS_GetScriptFilename where it wasn't before. (That function hasn't changed, but apparently our policy on script->filename being NULL has?)
Comment 13 timeless 2011-11-11 11:36:25 PST
write user: and use r=sfink
Comment 14 Steve Fink [:sfink] [:s:] 2011-11-11 11:38:51 PST
Created attachment 573871 [details] [diff] [review]
Handle null script filenames
Comment 15 Ed Morley [:emorley] 2011-11-12 04:55:05 PST
Comment 16 Robert Kaiser 2011-11-15 09:05:43 PST
This happens in 10.0a2 Aurora as well.
Comment 17 Jesse Kuhnert 2011-11-15 09:29:08 PST
This is definitely fixed. FYI
Comment 18 Jan Honza Odvarko [:Honza] 2011-11-15 11:07:13 PST
I can confirm both:
- I don't see the problem on Nightly any more
- Aurora crashes (waiting for the patch, which is only in Nightly so far, I guess)

Comment 19 Steve Fink [:sfink] [:s:] 2011-11-15 15:03:41 PST
Comment on attachment 573871 [details] [diff] [review]
Handle null script filenames

If I am interpreting , then this is crashing on Aurora. That doesn't seem like a good thing. Simple, safe fix. Requesting approval.
Comment 20 Steve Fink [:sfink] [:s:] 2011-11-15 15:04:20 PST
Oh, sorry. This appears to be causing bug 700311.
Comment 21 Robert Kaiser 2011-11-16 10:10:22 PST
*** Bug 701276 has been marked as a duplicate of this bug. ***
Comment 22 Daniel Veditz [:dveditz] 2011-11-17 14:43:04 PST
"causing"? you mean "fixes", right? bug 700311 comment 7
Comment 23 Steve Fink [:sfink] [:s:] 2011-11-17 15:05:18 PST
(In reply to Daniel Veditz from comment #22)
> "causing"? you mean "fixes", right? bug 700311 comment 7

Sorry. It's all a matter of perspective and ambiguous referents. I'll try to be more clear.

The fix attached to this bug should also fix bug 700311. I'll go dupe it.
Comment 24 Steve Fink [:sfink] [:s:] 2011-11-17 15:05:44 PST
*** Bug 700311 has been marked as a duplicate of this bug. ***
Comment 25 Jesse Kuhnert 2011-11-17 23:25:29 PST
It's the bug report that just keeps on giving. Every update is like a fresh bird dropping on my upturned innocent face. I'm pretty sure if I were a developer I'd apply a filter-to-****-trash on all bugzilla emails almost immediately.
Comment 26 Robert Kaiser 2011-11-21 08:02:10 PST
*** Bug 700564 has been marked as a duplicate of this bug. ***
Comment 27 Sheila Mooney 2011-11-22 09:57:00 PST
Triagers - we need to get this approved for Aurora.
Comment 28 Sheila Mooney 2011-11-22 14:49:56 PST
There are over 800 of these in the past 2 weeks. I only checked one of the signatures. It looks like it was introduced in 10 on the trunk.
Comment 29 Steve Fink [:sfink] [:s:] 2011-11-22 16:10:38 PST
Comment 30 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-28 14:22:00 PST
What are the steps to reproduce this bug so QA can verify the fix?
Comment 31 Jan Honza Odvarko [:Honza] 2012-01-02 04:06:23 PST
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #30)
> What are the steps to reproduce this bug so QA can verify the fix?

You can use my STR here:

Comment 32 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-01-04 13:05:08 PST
qa+ for verification using the following steps:

1) Install Firebug from here:
2) Restart Firefox, load and set it as the home page
3) Open Firebug and enable the Script panel
4) Restart, Firebug should be enabled by default
> Crash (you might need to restart several times)

NOTE: Sometimes the crash happens when shutdowning Firefox, sometimes when it's starting.
Comment 33 Simona B [:simonab ] 2012-01-05 08:00:44 PST
Verified as fixed using the steps from Comment 32 on:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0

Firefox does not crash when shutting down or starting.
Comment 34 Tim (fmdeveloper) 2012-02-03 15:40:59 PST
*** Bug 702650 has been marked as a duplicate of this bug. ***

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