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
Attachment #315318 - Attachment mime type: application/octet-stream → text/plain
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
Summary: Crash on Steps to reproduce from Bug 420187 → Crash [@ memcpy] on Steps to reproduce from Bug 420187
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.
Should probably clean this up in the future, but doesn't block.
Assignee: nobody → kengert
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.
also #21 topcrash on the trunk, so it is observable with a smaller population of users.
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....
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.
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.
Depends on: 431786
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.
WFM, Nightly on Linux64. Can anyone else still reproduce this crash?
Whiteboard: [closeme 2014-11-01]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.