428726 - Crash [@ memcpy] on Steps to reproduce from Bug 420187

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: mac crash report

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041218 Firefox/3.0pre ID:2008041218 as well on  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 and Nightly Build on XP

Steps to reproduce:
-> See Bug 420187 Comment#18, load some https sites, close firefox and restart
Firefox. After  restart (2-5 seconds, you  need to be very fast!) close firefox.
-> Assertion and Crash (will file a new Bug for the Crash)

I crashed not anytime, but in a lot of tries during testing this when i was very fast with closing Firefox. Does not crash when you Close Firefox and all tabs are finished loading

Also i got before the Crash : ###!!! ASSERTION: shared, but not terminated: 'str.mFlags & F_TERMINATED', file /debug/mozilla/xpcom/string/src/nsTSubstring.cpp, line 387 and filed Bug 428716 for this.

The XP Crash Report is http://crash-stats.mozilla.com/report/index/f1c21421-08e9-11dd-8a11-0013211cbf8a

Comment 1

[Martijn Wargers (dead)]

From http://crash-stats.mozilla.com/report/index/f1c21421-08e9-11dd-8a11-0013211cbf8a
0  	mozcrt19.dll  	memcpy  	 memcpy.asm:188
1 	xul.dll 	nsACString_internal::Assign 	mozilla/xpcom/string/src/nsTSubstring.cpp:346
2 	nspr4.dll 	FileWrite 	mozilla/nsprpub/pr/src/io/prfile.c:109

Comment 2

[Kai Engert (:KaiE:)]

Attachment: linux stack

I was able to reproduce this on Linux, using a nearly identical stack.
However, I crashed a couple of lines later nsURLHelper.cpp.

I also saw a crash with a different stack, see bug 428746.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Should probably clean this up in the future, but doesn't block.

Comment 4

[chris hofmann]

there are some other conditions that users seem to be hitting this, or other memcpy related crashes...   comments from b5 users

While using my ass of a connection (dialup) I find firefox (3.0b5), more often than not, will crash as a connection is lost.

Simple javascript reload for a progress bar. PFsense 1.2 actually. I rebooted the router and tried to load up google. No connection, so I waited and BOOM crash.

was refreshing the website.

stack on all three of these crash reports and other memcpy crashes looks like

Frame  	Module  	Signature [Expand]  	Source
0 	mozcrt19.dll 	memcpy 	memcpy.asm:188
1 	xul.dll 	xul.dll@0x23fea7 	
2 	xul.dll 	xul.dll@0x282a92 	

do we have some litmus tests that exercise connection dropouts while doing a variety of page loading and other activities that might help to surface a reproducable problem?

currently this is the #12 topcrash on beta 5 so we ought to try and keep going on debugging and fixing...

Comment 5

[Marcia Knous [:marcia]]

Currently we have some Litmus test cases which test dropped network connections in relation to software update, but not related to general testing. One of the problems is that the Moz QA team does quite a bit of testing using high bandwidth connections, but not as much with other types of connections. I have a test account that I use to test t-mobile wifi hotspots and the experience is very different than being in the office testing. I think we can improve in the area, but I am sure how much we can really do. I can certainly try some of these operations using my test account as well as using various slower connections which can often be found at libraries, etc.

Comment 6

[chris hofmann]

also #21 topcrash on the trunk, so it is observable with a smaller population of users.

Comment 7

[chris hofmann]

justin, and IT might also have some ideas on bandwidth-rate-limiting and error injecting proxies that we could set up and hook up to some of the testing machines.   we used to have something like this set up back in the day....

Comment 8

[Justin Fitzhugh]

Don't have anything off hand but there are tools to simulate specific network conditions we can get if needed - one that comes to mind was call "the cloud".  Let me know if this is needed, and I can do a bit more research.

Comment 9

[chris hofmann]

yes, its needed to do the kind of in-depth testing that we need for investigating this bug and others.   I file bug 431786 to track the other task of setting up a proxy that can assist with performance and reliability testing.

Comment 10

[Samuel Sidler (old account; do not CC)]

I don't think this is actually a topcrash. The majority of the [@ memcpy] crashes seem to be bug 444446 given the amount of sqlite in them. The stack chofmann mentions in comment 4 is a rare one afaict.

Comment 11

[Mats Palmgren (inactive)]

WFM, Nightly on Linux64.  Can anyone else still reproduce this crash?