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.
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.
I see crashes in Windows that started using the 2011110500 build. I will get the pushlog regression range.
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.
(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... ;-)
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.
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.
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).
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.
*** Bug 701121 has been marked as a duplicate of this bug. ***
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.
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.
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?)
write user: email@example.com and use r=sfink
Created attachment 573871 [details] [diff] [review]
Handle null script filenames
This happens in 10.0a2 Aurora as well.
This is definitely fixed. FYI
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 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.
Oh, sorry. This appears to be causing bug 700311.
*** Bug 701276 has been marked as a duplicate of this bug. ***
"causing"? you mean "fixes", right? bug 700311 comment 7
(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.
*** Bug 700311 has been marked as a duplicate of this bug. ***
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.
*** Bug 700564 has been marked as a duplicate of this bug. ***
Triagers - we need to get this approved for Aurora.
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.
What are the steps to reproduce this bug so QA can verify the fix?
(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:
qa+ for verification using the following steps:
1) Install Firebug from here:
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.
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.
*** Bug 702650 has been marked as a duplicate of this bug. ***