463803 - Crash [@ memcpy] [@ js_NewStringCopyN]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Martijn Wargers (dead)]

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

Comment 1

[Martijn Wargers (dead)]

Never mind, I seem to hit this crash when visiting ftp://mozilla.org and it happens even when jit is turned off.

Comment 2

[IU]

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? ;-)

Comment 3

[Martijn Wargers (dead)]

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.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 6

[timeless]

fwiw i filed bug 464099 based on comment 5

Comment 9

[David Mandelin [:dmandelin]]

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.

Comment 10

[Martijn Wargers (dead)]

If you can't reproduce, then it's probably not there anymore.

Comment 11

[John]

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

Comment 12

[John]

correction from above: Bug 464384

I also forgot to mention that I tried this on a fresh profile.

Comment 13

[(not currently active) Ted Mielczarek]

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

Comment 14

[Martijn Wargers (dead)]

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.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I missed to reopen this bug due to existent crash reports. We should evaluate why it only happens on some machines.

Comment 17

[Michael Lefevre]

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

Comment 18

[IU]

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.

Comment 19

[Jim Jeffery not reading bug-mail 1/2/11]

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.

Comment 20

[Larry Snow]

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

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 22

[David Mandelin [:dmandelin]]

Attachment: Patch

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.

Comment 23

[David Mandelin [:dmandelin]]

Pushed to tracemonkey as changeset:   21599:b42e1a6af7ca.

Comment 24

[David Mandelin [:dmandelin]]

Pushed as http://hg.mozilla.org/mozilla-central/rev/741151e3570e.

Comment 25

[Larry Snow]

Thanks David, glad to help.

Comment 26

[Jim Jeffery not reading bug-mail 1/2/11]

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 ?

Comment 27

[Jim Jeffery not reading bug-mail 1/2/11]

oops, any reason this was NOT closed - wishes at times bugzilla had an 'edit'

Comment 28

[Larry Snow]

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

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Lets mark it as resolved. We should monitor Soccorro if all the crashes are gone before verifying the fix.

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No crashes in the last three weeks. Setting verified keyword.