User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170504112025 Steps to reproduce: http://www.dslreports.com/speedtest on a very fast connection - speeds of 500-700 mbps. Choose cable and test, and it will crash. This used to work recently in Firefox, some update must have made it a problem. It still works in Chrome. Using Firefox ESR 52.1.1 32 bit Actual results: Tab Crashes with a Firefox message about the Tab Crashed Expected results: Speedtest should finish

Does not appear to be a problem with speedtest.net -- may be only a problem with dslreports.com speedtest

Reporter: Can you please add the crash report from about:crashes? Thanks.

Will this do: This one from about 9:30 this morning before I made the report: https://crash-stats.mozilla.com/report/index/d0c278fe-8ecc-4a2a-bb93-c23a50170509 This one from just now (made a fresh one): https://crash-stats.mozilla.com/report/index/06f16d47-2e7c-4443-ad69-8f7400170509

Hi Rich, I tested on latest Nigthly on Mac OS 10.11 with a very fast connection (as you can see) and I was not able to reproduce : http://www.dslreports.com/speedtest/15022599 Did you try with a fresh profile or at least on safe mode to disable your extensions?

I tried with safe mode. Here is the crash report: https://crash-stats.mozilla.com/report/index/4de4b4e6-5ee3-47f6-8948-7ea420170509 Maybe only does it on Windows. If I get time I may able to test with a different Windows machine tomorrow. Thanks

(In reply to rich.higby from comment #5) > I tried with safe mode. Here is the crash report: > https://crash-stats.mozilla.com/report/index/4de4b4e6-5ee3-47f6-8948- > 7ea420170509 > > Maybe only does it on Windows. If I get time I may able to test with a > different Windows machine tomorrow. > > Thanks Also that crash report unfortunately isn't likely very actionable and is related to an out of memory condition, so I am not sure if the issue could be addressed.

User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID 20170528030206 I was able to reproduce the OOM crash on Windows 10 using the latest Nightly 55.0a1 x32 and x64. I also have a fairly high network speed ~300mbps. The crashes seem to happen much more quickly on x32 builds so I've used those to find a regression range: Last good revision: ca17ce6a2c9a3e906c9527c1e44c98185325cabe First bad revision: c634201ba01d846403e692921a44038d2e55817a Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ca17ce6a2c9a3e906c9527c1e44c98185325cabe&tochange=c634201ba01d846403e692921a44038d2e55817a Looks like the following bug has the changes which introduced the regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1202006 Andrea, could you please take a look at this?

After talking to Ryan, he suggested that Core::IPC is a more suitable component given the crash stack.

I wish I had a 300mbps connection at home. I cannot reproduce it locally and the crash-report is not helping to identify the issue. billm, any idea?

I would add some printfs to monitor the total amount of memory allocated to BufferList data structures. If it gets very large, even if it doesn't crash, then you can try to understand why that happens.

Is this possibly related to bug 1349862?

I guess this is rather related to (or even a dupe of) bug 1373222.

It seems right. I mark this bug as a duplicateof 1373222. If somebody can test it, in case I'm wrong, please reopen this bug.

Per bug 1373222, mark 54 won't fix and 55/56 fixed.