Closed Bug 463803 Opened 13 years ago Closed 13 years ago

Crash [@ memcpy] [@ js_NewStringCopyN]

Categories

(Core :: JavaScript Engine, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla1.9.1b2

People

(Reporter: martijn.martijn, Assigned: dmandelin)

References

()

Details

(Keywords: crash, regression, verified1.9.1)

Crash Data

Attachments

(1 file)

I'm getting this crash with current trunk build and with jit enabled, if wanted I might be able to get a minimized testcase.

http://crash-stats.mozilla.com/report/index/39ac6963-ada4-11dd-b118-001a4bd43ef6?p=1
0  	mozcrt19.dll  	memcpy  	memcpy.asm:407
1 	js3250.dll 	js_NewStringCopyN 	js/src/jsstr.cpp:2893
2 	js3250.dll 	js_ExecuteRegExp 	js/src/jsregexp.cpp:3909
3 	js3250.dll 	match_or_replace 	js/src/jsstr.cpp:1362
4 	js3250.dll 	js_StringMatchHelper 	js/src/jsstr.cpp:1423
5 	js3250.dll 	str_match 	js/src/jsstr.cpp:1437
6 	js3250.dll 	js3250.dll@0xb0ca7 	
7 	js3250.dll 	js_Execute 	js/src/jsinterp.cpp:1550
8 	js3250.dll 	JS_EvaluateUCScriptForPrincipals 	js/src/jsapi.cpp:5187
9 	xul.dll 	nsJSContext::EvaluateString 	dom/src/base/nsJSEnvironment.cpp:1586
10 	xul.dll 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:646
11 	xul.dll 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:556
12 	xul.dll 	nsScriptLoader::ProcessScriptElement 	content/base/src/nsScriptLoader.cpp:510
13 	xul.dll 	nsContentUtils::HasNonEmptyTextContent 	content/base/src/nsContentUtils.cpp:3674
14 	xul.dll 	nsScriptElement::MaybeProcessScript 	content/base/src/nsScriptElement.cpp:188
Never mind, I seem to hit this crash when visiting ftp://mozilla.org and it happens even when jit is turned off.
I'm also crashing, but with JIT-content enabled and at: http://watch.ctv.ca/news

http://crash-stats.mozilla.com/report/index/4d9a0554-adc3-11dd-ba0e-001cc45a2c28

Maybe JIT is just helping it crash faster? ;-)
I'm getting this crash also when entering error pages, like for instance when I'm in offline mode and get the offline error page.
This looks like a blocker to me.
Severity: critical → blocker
Flags: blocking1.9.1?
Keywords: regression
Flags: blocking1.9.1? → blocking1.9.1+
Summary: Crash [@ memcpy] → Crash [@ memcpy] [@ js_NewStringCopyN]
Same crash for me with the network timeout error page. Trying to load http://openlab.ring.gr.jp/skk/skk/dic/SKK-JISYO.L (~4MB) shows up the error page and lets Minefield crash immediately. I'll try to give a stacktrace when my build has been finished.
The regexp tracer seems to always be enabled if tracing is compiled in; it doesn't use the same pref.  That's probably a bug.
fwiw i filed bug 464099 based on comment 5
Duplicate of this bug: 464384
Duplicate of this bug: 464238
Would you mind checking if this still occurs in trunk builds as of 12 Nov 2008?
I don't get this crash on any of the sites listed here, so I'm wondering if it
was fixed by one of the bugfixes put in yesterday, or if it's a configuration
difference between my machine/build and yours.
If you can't reproduce, then it's probably not there anymore.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
This absolutely needs to be reopened. As per Bug 46384 (marked as a dupe of this one), it still crashes 100% of the time on startup if no internet adapter is assigned an IP address. Try disconnecting from your wireless or unplugging your ethernet (or both) and then start Minefield. Crash!

http://crash-stats.mozilla.com/report/index/0fe6abc3-3eff-4c57-a319-de7d20081112
correction from above: Bug 464384

I also forgot to mention that I tried this on a fresh profile.
I can still reproduce with today's nightly on Win32:
http://crash-stats.mozilla.com/report/index/ec10d251-b9b9-4505-b07d-03a820081112?p=1

STR:
1) Visit a hostname that doesn't resolve
2) There is no step 2
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I tried now using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre
And it seems to be worksforme.
(In reply to comment #14)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081112
> Minefield/3.1b2pre
> And it seems to be worksforme.

Same here with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre ID:20081112034733.

I cannot get it to crash with a non-existent domain or when disconnected.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → WORKSFORME
I missed to reopen this bug due to existent crash reports. We should evaluate why it only happens on some machines.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm afraid I can't reproduce using any of the steps previously suggested, but I just crashed using today's Windows build.
http://crash-stats.mozilla.com/report/index/b1020993-bb86-4bdc-89a6-ae3920081112
I was able to reproduce this crash.  Do the following (in sequence):

1. Create a new profile
2. Launch Minefield
3. Go to Tools -->Options -->Main
4. Set startup to "Show my windows and tabs from last time"
5. Go to Advanced -->Network
6. Set cache to 0 MB.  Click OK
7. Close Minefield
8. Disable your network adapter
9. Launch Minefield.
10. If you don't crash, enable your network adapter, refresh the tabs that failed to load (get them loaded with the original web content again); and then repeat from Step 7.
From the original bug that was duped to this one: 

Reports of crashes when using MVPS hosts file for ad-blocking, and protection
from malware sites. 

Builds on 11/7/2008 are OK, builds starting on 11/8/2008 and since are
failing/crashing. 

Link to hosts file being used:
http://www.mvps.org/winhelp2002/hosts.txt

Spoke with person on IRC this evening earlier and he reports its still crashing if you have the host-file noted above just be visiting a site that's ad heavy: CNN for instance.
Yep, that is true.  It still crashes on CNN.com for example with the latest hourly and the current MVPS HOSTS file.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081112 Firefox/3.0 ID:20081112144709
A similar crash happend for me while starting Firefox. The browser window was visible around 1 second.

bp-19cecf52-353a-4e8c-a887-a5ca20081112:

0  	mozcrt19.dll  	fastcopy_I  	
1 	mozcrt19.dll 	_VEC_memcpy 	
2 	mozcrt19.dll 	malloc 	obj-firefox/memory/jemalloc/src/jemalloc.c:5988
3 	js3250.dll 	js_NewStringCopyN 	js/src/jsstr.cpp:2893
Attached patch PatchSplinter Review
This should take care of it. The comment inside the patch explains the cause. ++gal for suspecting that using the regex pattern+flag as the key instead of the regexp pointer would also avoid the problem.

Thanks to everyone above for finding this and providing instructions to duplicate it--I had a really hard time duplicating. Comments 19 and 20 were particularly helpful.
Assignee: general → dmandelin
Attachment #348099 - Flags: review?(gal)
Attachment #348099 - Flags: review?(gal) → review+
Pushed to tracemonkey as changeset:   21599:b42e1a6af7ca.
Thanks David, glad to help.
Just spoke to person on IRC that having the crash with the Hosts file, and he reports all is OK now, no crashes. 

any reason this was closed with the push from yesterday ?
oops, any reason this was NOT closed - wishes at times bugzilla had an 'edit'
Yes this was fixed late last night and all is well.  HOSTS file works fine now.  Thanks.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081113 Firefox/3.0 ID:20081113223638
Lets mark it as resolved. We should monitor Soccorro if all the crashes are gone before verifying the fix.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
We are still limited in searching on Soccorro but as far as I can see there is no crash listed anymore with this stack trace for 3.1b2pre and 3.1b2. I'll mark as Verified.
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.1b2
No crashes in the last three weeks. Setting verified keyword.
Flags: in-testsuite-
Flags: in-litmus-
Duplicate of this bug: 468630
Crash Signature: [@ memcpy] [@ js_NewStringCopyN]
You need to log in before you can comment on or make changes to this bug.