These all look the same to me, but for completeness: http://crash-stats.mozilla.com/report/index/bp-c62670f0-dc79-4a56-b3d8-8d80f2100111 http://crash-stats.mozilla.com/report/index/bp-790fa024-a850-446a-9be8-ad6ac2100111 http://crash-stats.mozilla.com/report/index/bp-f47964c2-faa0-4b8e-a96e-5090b2100111 http://crash-stats.mozilla.com/report/index/bp-989c5d85-c5c1-40b0-a934-da8f52100111 The crashing page (behind vpn): http://jbalogh.khan.mozilla.org/amo/site/en-US/developers/versions/add/2313 Our preview site (should be the same as the original page, but I didn't crash when I tried the upload once): https://preview.addons.mozilla.org/en-US/developers/versions/add/2313 If you want an account on preview.AMO to try this out, let me know. The file I was trying to upload: http://people.mozilla.org/~jbalogh/lightning-linux-1.0b.xpi I'm on 3.6pre from this morning. about:buildconfig says it's http://hg.mozilla.org/releases/mozilla-1.9.2/rev/05a4cc93f14b

Signature NS_CopySegmentToBuffer(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) UUID c62670f0-dc79-4a56-b3d8-8d80f2100111 Time 2010-01-11 10:44:57.605761 Uptime 7192 Last Crash 1121308 seconds before submission Product Firefox Version 3.6pre Build ID 20100111033925 Branch 1.9.2 OS Mac OS X OS Version 10.6.2 10C540 CPU x86 CPU Info GenuineIntel family 6 model 7 stepping 6 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x36f00000 User Comments Processor Notes Crashing Thread Frame Module Signature [Expand] Source 0 @0xffff08ab 1 XUL NS_CopySegmentToBuffer xpcom/io/nsStreamUtils.cpp:763 2 XUL nsBufferedInputStream::ReadSegments netwerk/base/src/nsBufferedStreams.cpp:331 3 XUL nsBufferedInputStream::Read netwerk/base/src/nsBufferedStreams.cpp:314 4 XUL nsMultiplexInputStream::Read xpcom/io/nsMultiplexInputStream.cpp:207 5 XUL nsMultiplexInputStream::Read xpcom/io/nsMultiplexInputStream.cpp:207 6 XUL nsMultiplexInputStream::Read xpcom/io/nsMultiplexInputStream.cpp:207 7 XUL nsBufferedInputStream::Fill netwerk/base/src/nsBufferedStreams.cpp:378 8 XUL nsBufferedInputStream::ReadSegments netwerk/base/src/nsBufferedStreams.cpp:342 9 XUL nsHttpTransaction::ReadSegments netwerk/protocol/http/src/nsHttpTransaction.cpp:458

This and bug 541314 are Firefox 3.6 (rv:1.9.2) on MacOsX-Intel. Bug 570863 is SeaMonkey 2.1a1pre (rv:1.9.3a5pre i.e. trunk) on Linux-i686. Setting bug header fields in consequence.

It's #5 top browser crasher on Mac OS X in 15.0a2.

QA - can you try out the URL in this bug as well as the URLs that are provided once the needURLs request is filled?

Total Count URL 2 http://www.slashfilm.com/ 1 http://www.free-tv-video-online.me/player/movshare.php?id=bubo02w3lfv27 1 http://newalbumreleases.net/ 1 about:newtab 1 http://fast2ch.dip.jp/link.cgi?url=http%3a%2f%2fblog%2elivedoor%2ejp%2fmisopan_n 1 http://logsoku.com/thread/awabi.2ch.net/mnewsplus/1340189843/ 1 http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120625120622 1 http://www.bib.umontreal.ca/Proxy 1 http://www.gnc.com/home/index.jsp 1 http://www.ebay.co.uk/sch/i.html?_from=R40&_trksid=p5197.m570.l1313&_nkw=intel+m 1 http://www.youtube.com/watch?v=Y-5By8rAHpI 1 http://crooksandliars.com/ 1 https://78811.cloud.vimeo.com/ 1 http://www.hulkshare.com/zmqi412jfudi 1 http://gorillavid.in/7yj5kvf8t20c 1 http://forum.wawa-mania.cc/viewtopic.php?id=1312367 1 http://nedvizh.mmr.locum.ru/administrator/index.php?option=com_installer&view=in 1 http://www.slashfilm.com/superhero-bits-246/3/ 1 http://mp3skull.com/mp3/passion_pit_take_a_walk_m_machine.html 1 http://www.quickmeme.com/meme/3ptxcc/ 1 http://www2.tricities.com/ 1 https://my.usajobs.gov/GetJob/ViewDetails/319639400 1 http://www.telenovelasgratis.com/2011/08/el-joe-la-leyenda-capitulo-45-viernes-5 1 http://www.20min.ch/ 1 http://www.manson.com.br/marilyn-manson/simbologias/logos-e-simbologias/ 1 http://www.rocknytt.net/ 1 http://toronto.kijiji.ca/f-pets-dogs-puppies-for-sale-W0QQCatIdZ126QQPageZ2QQmax 1 http://suchen.mobile.de/auto-inserat/mercedes-benz-s-420-mercedes-benz-s420-w140 1 http://thepiratebay.se/torrent/5454218/Mathworks_Matlab_R2010a_UNIX_ISO-TBE

One comment indicates "Leaving page when uploading a Video with the Flash uploader"

I was unable to get any of the above URLs to crash in Firefox 15.0a2 2012-06-27 with Flash 11.3.300.257. Additionally, I tried several other video uploading services which appeared to use Flash (youtube, vimeo, metacafe) and was unable to get crashes there either.

(In reply to Marcia Knous [:marcia] from comment #8) > One comment indicates "Leaving page when uploading a Video with the Flash > uploader" This comment is about Fx 13 and the stack in comment 1. There are no comments after the spike in 15.0a1. It's now #1 unfixed top crasher in 15.0a2 on Mac OS X. The first frames of the stack are: Frame Module Signature Source 0 @0x7fffffe00800 1 XUL NS_CopySegmentToBuffer nsStreamUtils.cpp:726 2 XUL nsStorageInputStream::ReadSegments nsStorageStream.cpp:419 3 XUL nsInputStreamTransport::Read nsStreamTransportService.cpp:198 4 XUL nsStreamCopierOB::FillOutputBuffer nsStreamUtils.cpp:529 5 XUL nsPipeOutputStream::WriteSegments nsPipe3.cpp:1104 6 XUL nsStreamCopierOB::DoCopy nsStreamUtils.cpp:546 7 XUL nsAStreamCopier::Process nsStreamUtils.cpp:286 8 XUL nsAStreamCopier::Run nsStreamUtils.cpp:402 9 XUL nsThreadPool::Run nsThreadPool.cpp:185 10 XUL nsThread::ProcessNextEvent nsThread.cpp:624 11 XUL NS_ProcessNextEvent_P nsThreadUtils.cpp:213 12 XUL nsThread::ThreadFunc nsThread.cpp:257 It appeared first in 15.0a1/20120601, then in 16.0a1/20120607. A 6-day regression range before 15.0a1/20120601 is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4574b46f0ba&tochange=73783bf75c4c

Dup of bug 722034? It has the same regression range.

Probably a dupe of bug 764171, for which we just checked in a fix today. Let's see what effect the patch in bug 764171 has.

There are no crashes after 16.0a1/20120628065213. The working range might be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9bf5e71c5746&tochange=4a8e0d5fc954 Bug 764171 belongs to this window.

Is there anything more QA can do here? We've been unsuccessful in reproducing this bug, and it looks like we need to wait for bug 764171 to be resolved first.

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #14) > Is there anything more QA can do here? We've been unsuccessful in > reproducing this bug, and it looks like we need to wait for bug 764171 to be > resolved first. Agreed. Brian - please move forward with nominating bug 764171 for FF15 approval.

The code that likely caused the spike in crashes for 15 was backed out in bug 722034 comment 78. Crash-stats shows that the last FF15 crash for this was a 2012-07-10 crash ID, which is exactly the day I did that backout. This is an old bug and there are likely other pre-existing causes of these crashes, so I am leaving this bug open.

We should be releasing 15.0b1 today -- let's evaluate crashstats in Tuesday's meeting to determine the affect of comment 16. Keeping qawanted on this bug until then.

http://bit.ly/QOfq7x No crashes for 15b1 with this signature, so this looks good.

Like I mentioned above comment 12, I believe this is a dupe of bug 764171 and that this was fixed by the fix for that bug. We need to verify that this is not a problem in Firefox 16.

There are only four crashes in 15.0.1 and no crashes in 16.0 Beta: https://crash-stats.mozilla.com/report/list?signature=NS_CopySegmentToBuffer

Virgil can you please test this to satisfy Brian's concerns? It appears as though the fix for bug 764171 landed on June 28. Please test this with a pre-June 28 Firefox 16 build and a post-June 28 Firefox 16 build. If it crashes before and not after, I think that (in conjunction with Scoobidiver's comment) will satisfy Brian's concerns. Thanks

(In reply to Scoobidiver from comment #20) > There are only four crashes in 15.0.1 and no crashes in 16.0 Beta: > https://crash-stats.mozilla.com/report/list?signature=NS_CopySegmentToBuffer Of the four 15.x crashes: * One seems to be a problem with nsMIMEInputStream * Two seems to be an NPAPI issue * One seems to be related to HTTP, but with a much different signature. So, it seems like this is OK, just judging from crash-stats, and from what I remember from the other work that was done (bug 764171).

So should *this* bug be marked resolved fixed by bug 764171? Does Virgil still need to do any testing around this?

Fixed by bug 764171.