Closed Bug 1748264 Opened 3 years ago Closed 3 years ago

Firefox 95.0.2 hangs on Linux Mint 17.3 Cinnamon 64-bit

Categories

(Firefox :: Untriaged, defect)

Firefox 95
x86_64
Linux
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: blackhalt, Unassigned)

Details

(Keywords: hang, regression, Whiteboard: QA-not-reproducible)

Steps to reproduce:

Firefox 95.0.2 crash on Linux Mint 17.3 Cinnamon 64-bit.

Actual results:

Impossible close any Firefox window - freeze.

Expected results:

Firefox freeze.
You need kill Firefox.

Back to Firefox/94.0

Please provide the crash ID from about:crashes :
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report explains how to do this. When doing so, please also add the keyword "crashreportid" to the "Keywords" field of this report.

Flags: needinfo?(blackhalt)

(In reply to BlackHalt from comment #0)

Impossible close any Firefox window - freeze.

Please see if the following article helps:
https://support.mozilla.org/kb/firefox-hangs-or-not-responding

Back to Firefox/94.0

Since the issue only cropped up in the latest version, it would be helpful if you could determine the exact regression range.
https://mozilla.github.io/mozregression/quickstart.html

(In reply to Andre Klapper from comment #1)

Please provide the crash ID from about:crashes :

There is no crash. Firefox freezes (hangs) and must be forcibly terminated. There likely wouldn't be anything under about:crashes anyway, since that only works in builds from mozilla.org. Most Linux users either get Firefox from their distro, or compile it themselves.

https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report explains how to do this.

That page is gone. The correct link is now How to get a stacktrace for a bug report.

Severity: -- → S2
Has Regression Range: --- → no
Keywords: hang, regression
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Summary: 95.0.2 crash → Firefox 95.0.2 hangs on Linux Mint 17.3 Cinnamon 64-bit
Type: enhancement → defect

Is this any better with 96 (released this week)? If not, under what circumstances does this happen? Straight on startup or later on / when you do something specific? Can you gather more information so we can reproduce this based on the suggestions in comment 2?

Severity: S2 → --

I got the very same problem with 96.
Also using Cinnamon (5.0.6) on Debian 64bit

Complete desktop freezes, can't change windows
GeckoMain process tops in CPU
after killing GeckoMain desktop needs ~10s before being responsive again

(In reply to roland from comment #4)

I got the very same problem with 96.
Also using Cinnamon (5.0.6) on Debian 64bit

Under what circumstances does this happen? Straight on startup or later on / when you do something specific? Can you gather more information so we can reproduce this based on the suggestions in comment 2?

And is this with a mozilla.org build or Firefox from your distro? If the latter, does it reproduce with an official build?

Flags: needinfo?(roland)

Problem happens with build of my distro. Browser works normally, but at some point (cant tell what the exact action is) browser shows delayed actions (e.g. popups showing for mouse over positions from 30s before), then screen seems to freeze completely (except for mouse cursor). Clock updateing with increasing delays (some minutes)

After killing GeckoMain, system needs some seconds to recover: Browser window vanishes, then system is performing again.

I will try to reproduce with official firefox distro

Problem hasn't occured for some hours of working with the official build.
Seems to be a problem with debian's build

Flags: needinfo?(roland)

(In reply to roland from comment #8)

Problem hasn't occured for some hours of working with the official build.
Seems to be a problem with debian's build

:glandium, do you know how to proceed here?

Flags: needinfo?(mh+mozilla)

Hello I have tried to reproduce the issue with Ubuntu 20.04 on firefox 99.0a1(2022-02-28) unfortunately I wasn't able to reproduce the issue. I will add the QA-not-reproducible tag.

Whiteboard: QA-not-reproducible

Getting info from about:memory would likely have been useful, as the described behavior sounds like a memory leak, but potentially in a system library.

Given that there was no further response from the original reporter, I don't see what we can do here.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(blackhalt)
You need to log in before you can comment on or make changes to this bug.