[Tracking Requested - why for this release]: hang Build Identifier: https://hg.mozilla.org/mozilla-central/rev/564b225d553547fe4aa9a1039278f695c9507db9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160413030239 **original report http://forums.mozillazine.org/viewtopic.php?p=14572229#p14572229 This seems to be e10s specific bug. Reproduced on Nightly48.0a1, but not on Aurora47.0a2. Steps To Reproduce: 1. Open several tabs (e.g., [about:home][about:home][about:home]) 2. Open https://upload.wikimedia.org/wikipedia/commons/8/88/Arthur_(hi_res).jpg in a new tab 3. Wait for loading the image 4. Right click on the image and Copy image. --- observe 100% core CPU usage 5. Switch tabs --- observe Nightly becomes unresponsive and hangs with 100% core CPU. Actual Results: Nightly.exe consumes 100% core CPU. Nightly becomes unresponsive and hangs with 100% core CPU. Sometimes(not often), the content of all tabs gets replaced with a spinning throbber. Expected Results: not so.

Tried the STR and did not see what Alice sees. CPU% was negligible. Application Basics ------------------ Name: Firefox Version: 48.0a1 Build ID: 20160413073236 Update Channel: default User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0 OS: Windows_NT 10.0 x86-64 Multiprocess Windows: 1/1 (Enabled by user) Safe Mode: false Graphics -------- Adapter Description: AMD Radeon (TM) R9 390 Series Adapter Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 4095 Asynchronous Pan/Zoom: wheel input enabled; touch input enabled ClearType Parameters: D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] Device ID: 0x67b1 Direct2D Enabled: true DirectWrite Enabled: true (10.0.10586.0) Driver Date: 4-3-2016 Driver Version: 16.150.2211.1001 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 00000000 Supports Hardware H264 Decoding: Yes; Using D3D11 API Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote: true AzureCanvasAccelerated: 0 AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo

Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=74d3c0c9b49c4714f4791577cf7d3f31d147fe19&tochange=d20bb8617b2597b89456413119b40ff02bf77b09 Suspect: dd3e03fcb06b Bill McCloskey — Bug 1235633 - IPC OOM mitigation by eliminating buffer copying (r=jld)

Stack using crashfirefox.exe (during 100% core usage): bp-d905e0f5-6e65-46f1-b257-ffba52160413

I can reproduce.

When there's a huge message coming in, we would call reserve to reserve lots of space for it. Then we would read in 4K and call assign, which would realloc the buffer to be only as big as how much we had read so far. The next time through we would reserve a ton of space again and then realloc at the end. This patch avoids the assign() operation so that we reserve once and use that memory for the entire message, as intended.

Comment on attachment 8741171 [details] [diff] [review] patch Review of attachment 8741171 [details] [diff] [review]: ----------------------------------------------------------------- r=me if it passes Try.

Recent regression, tracking in case it reopens