700302 - trunk crash in strlen coming from jsds_FilterHook (via nsDependentCString::nsDependentCString?)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Robert Kaiser]

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 https://crash-stats.mozilla.com/report/list?signature=strlen%20|%20jsds_FilterHook%28JSDContext*%2C%20JSDThreadState*%29 - the 32bit variant seems to be e.g. bp-45e0579d-b571-41fa-8c60-c7cd02111107 and https://crash-stats.mozilla.com/report/list?signature=strlen%20|%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]

It looks like bp-f2aaa844-2a19-4abd-ba64-1d16f2111106 is a Linux example, see https://crash-stats.mozilla.com/report/list?signature=jsds_FilterHook for more Linux reports with the jsds_FilterHook signature.

Comment 2

[Marcia Knous [:marcia]]

I see crashes in Windows that started using the 2011110500 build. I will get the pushlog regression range.

Comment 3

[Marcia Knous [:marcia]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3491b2f021bf&tochange=ae9e5bf847fc 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]

(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]

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]]

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] (inactive)]

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).

bp-13a15cdb-c741-45db-813d-5c5f52111108
bp-d6a0977c-2dc3-423d-8325-9ed5e2111108
bp-29ea163c-640f-42e5-84f6-d30a82111108
bp-cae1b545-33c4-43b2-92b5-0603d2111108

Comment 8

[Bob Clary [:bc] (inactive)]

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 10

[James Long (:jlongster)]

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]

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:]]

Attachment: 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]

write user: [e-mail] and use r=sfink

Comment 14

[Steve Fink [:sfink] [:s:]]

Attachment: Handle null script filenames

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/1d5bd2173fa1

Comment 16

[Robert Kaiser]

This happens in 10.0a2 Aurora as well.

Comment 17

[Jesse Kuhnert]

This is definitely fixed. FYI

Comment 18

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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)

Honza

Comment 19

[Steve Fink [:sfink] [:s:]]

Comment on attachment 573871 [details] [diff] [review]
Handle null script filenames

If I am interpreting https://crash-stats.mozilla.com/report/list?signature=msvcr80.dll%400x14500 , 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:]]

Oh, sorry. This appears to be causing bug 700311.

Comment 22

[Daniel Veditz [:dveditz]]

"causing"? you mean "fixes", right? bug 700311 comment 7

Comment 23

[Steve Fink [:sfink] [:s:]]

(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 25

[Jesse Kuhnert]

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 27

[Sheila Mooney]

Triagers - we need to get this approved for Aurora.

Comment 28

[Sheila Mooney]

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:]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c8ac669e318f

Comment 30

[u279076]

What are the steps to reproduce this bug so QA can verify the fix?

Comment 31

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(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:
https://bugzilla.mozilla.org/show_bug.cgi?id=700311#c1

Honza

Comment 32

[u279076]

qa+ for verification using the following steps:

1) Install Firebug from here: 
http://getfirebug.com/releases/firebug/1.9/firebug-1.9.0a5.xpi
2) Restart Firefox, load www.google.com 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 Badau, Desktop QA]

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.