Closed Bug 1504140 Opened 6 years ago Closed 5 years ago

Tabs crashing systematically on numerous specific pages since 63.0

Categories

(Firefox :: Untriaged, defect)

63 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: fabrice, Unassigned)

Details

(Whiteboard: [triagemonth-2018-12])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Open tab
Go to: https://support.mozilla.org/en-US/questions/1175046


Actual results:

Tab crashes ("Gah! your tab just crashed")

In console window, got the following messages:
----
[Parent 3552, Gecko_IOThread] WARNING: pipe error (177): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 356
[Parent 3552, Gecko_IOThread] WARNING: pipe error (191): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 356
[Parent 3552, Gecko_IOThread] WARNING: pipe error (173): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 356

###!!! [Parent][MessageChannel] Error: (msgtype=0x190084,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
----

Happens systematically on some pages (found tens of them while googling "firefox 63 your tab just crashed"

Linux 64 bits (CentOS 7)

No add-ons installed.

/!\ The problem do NOT occur in safe-mode. I've tested some of the pages I've had crashes with in safe mode: none made the tab crash.

The problem does occur with a fresh profile (close firefox; rm -rf .mozilla; run firefox again, access https://support.mozilla.org/en-US/questions/1175046: tab crashes)



Expected results:

Tab should not crash
Forgot to mention: happening since 63.0, now running 63.0.1 (64 bits)

Feel free to ask more info or to perform some tests.
I've seen the error a few times as well, although I couldn't connect it to any tab crash. I find it really weird that in safe mode you don't get the same behavior.
On a hunch, could you please try to disable hardware acceleration and see afterwards if you get any tab crash? 
(open about:preferences / Performance and uncheck "Use Hardware acceleration when available")
Flags: needinfo?(fabrice)
Thank you for looking into it. I tested with hardware acceleration disabled and, for what it's worth, Content process limit set to 1: same issue, tabs keep crashing.
I get the same issue. I tried to install old versions (64.0b7 crash too)
With 61.0.2, the whole browser crashed this time, not only tab. It could gave me a crash dumb. I could see that it's about signature nsSSLStatus::~nsSSLStatus. 

When using early version, we could see that when connecting to google maps, the connection was not secure. In safe mode, the connection was secure.
Workaround for me :
Deactivating webGL in about:config => webgl.disabled;true 
Solution from https://support.mozilla.org/en-US/questions/1233994
Thanks for the input. This workaround does not work for me.
Disabling every webgl related settings (webgl.disabled, webgl.disable-DOM-blit-uploads, webgl.disable-angle, webgl.disable-extensions, webgl.disable-fail-if-major-performance-caveat, webgl.disable-wgl) does not work either.
Flags: needinfo?(fabrice)
I have this problem too on Centos 7 (on safe mod ok, on 32bit ok) on 64bit (clean profile) tab crash, on 64bit (normal profile) tab crash
Try:
Deactivating webGL in about:config => webgl.disabled;true 
Not helps

You can check this site - it always crashed: https://draculatheme.com
Same here.. tabs crashing often on certain pages, will totally lock-up browser (FF 63.0.3) have to use task-manager to shutdown.

I've tried safe mode (no extensions) also deleting webGL etc. I've refreshed Firefox twice. And as a last resort tonight I deleted FF totally and reinstalled it. Up to now It's locked up twice tonight. Doesn't seem related to any particular webpages... I will just see that the little as the tab/page is loading will continue to go from side to side but the browser is totally locked up.
In reply to Comment 9: this does not look like the same issue for these reasons: crash is systematic for us on concerned pages (not often), browser is not locked up for us, and it impacts specific web pages. Maybe you want to open a dedicated ticket.
As deactivating webgl works for me (I can still get the draculatheme page for example), I cannot reproduce your issue.

But I noted that when tab crash, previous versions can give you crash reports while earlier doesn't.
So is it your case and did you try with an old version(after having the issue)? Maybe you could get more data about why it still crash.
Just upgraded to version 64.0. I don't see any problem anymore.
I'll see how FF 64 goes. Thanks
Hey fabrice,

I just saw you saying you are not having this issues in 64. Are you still able to reproduce this bug? If not, we can resolve the bug as WORKSFORME.

Thank you for taking your time to file this issue.
Flags: needinfo?(fabrice)
Whiteboard: [triageday-2018-12-19] → [triagemonth-2018-12]
I've not been using FF on the Win 7 side of the system for a couple of days now, as I've needed Win10 which is available on another drive, however a family member said a tab crashed the other day for them so I checked the logs and there was one created, so I've reported it... This was the number..

bp-8cb6bcc1-f6fe-4b36-b846-e994f0181219
(In reply to Hossain Al Ikram [:ikram] (QA Contact) from comment #14)
> Hey fabrice,
> 
> I just saw you saying you are not having this issues in 64. Are you still
> able to reproduce this bug? If not, we can resolve the bug as WORKSFORME.
> 
> Thank you for taking your time to file this issue.

Hello,
I confirm that with Firefox version 64 I cannot reproduce this problem on any of the pages I had a problem before.
Regards,
Fabrice
Flags: needinfo?(fabrice)

I haven't seen any crash report with the Signature: BaseAllocator::free | je_free | mozilla::FrameLayerBuilder::BuildContainerLayerFor in the last 2 weeks and based on comment 16, let's mark this as WFM until further information can tell us how to reproduce this and thus reopen it if need be.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.