[6.8.0.50+] Windows server and/or system level freeze
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: baphijmm, Unassigned, NeedInfo)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Steps to reproduce:
Literally just running the program in Linux. Specifically, I'm running Linux Mint, version 22 (Wilma). Issue began with previous kernel (6.8.0.50), but persists in current one (6.8.0.51). While 133.0.3 did fix the problem SOMEWHAT (whereas 133.0.0 was WHOLLY broken), it does still occur, and will occur with a chance approaching 100% depending on how long the browser runs.
Actual results:
The browser completely kills any and all response from the OS, including all human input (keyboard and mouse) and occasionally going so far as to kill video output as well; the only solution is to reboot the computer, at which point there is a chance the compression algorithm of the OS has been so thoroughly broken that a fsck and dpkg in Recovery Mode are required in order to get back into the OS.
Expected results:
Literally not that! Just operating without bricking my computer is what should have happened!
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 months ago
|
||
(In reply to baphijmm from comment #0)
Actual results:
The browser completely kills any and all response from the OS, including all human input (keyboard and mouse) and occasionally going so far as to kill video output as well
Do you mean sometime the browser still plays video but the machine does not response to any input event?
Is it possible to connect to your computer through network from another one while it happens?
Updated•2 months ago
|
(In reply to Thinker Li [:sinker] from comment #2)
(In reply to baphijmm from comment #0)
Actual results:
The browser completely kills any and all response from the OS, including all human input (keyboard and mouse) and occasionally going so far as to kill video output as well
Do you mean sometime the browser still plays video but the machine does not response to any input event?
Is it possible to connect to your computer through network from another one while it happens?
No, I am referring to the literal video output of the computer; in other words, on occasion, it will break so hard that the monitor no longer displays anything, or any sign that anything is connected to it.
It is not possible to connect to the computer from another while this is occurring, no.
Comment 4•2 months ago
|
||
(In reply to baphijmm from comment #3)
No, I am referring to the literal video output of the computer; in other words, on occasion, it will break so hard that the monitor no longer displays anything, or any sign that anything is connected to it.
It sounds more like a kernel/OS issue, not an issue of Firefox.
An OS should not allow an application to crash or froze the machine in any circumstances.
If an application like Firefox tries to hurt the system, the application should crash, not the OS/machines itself.
I would suggest you to talk with Linux Mint community. They should be in the better position
to fix your issue.
(In reply to Thinker Li [:sinker] from comment #4)
(In reply to baphijmm from comment #3)
No, I am referring to the literal video output of the computer; in other words, on occasion, it will break so hard that the monitor no longer displays anything, or any sign that anything is connected to it.
It sounds more like a kernel/OS issue, not an issue of Firefox.
An OS should not allow an application to crash or froze the machine in any circumstances.
If an application like Firefox tries to hurt the system, the application should crash, not the OS/machines itself.
I would suggest you to talk with Linux Mint community. They should be in the better position
to fix your issue.
This was not an issue in a previous version of the Linux kernel, with the most recent version of Linux Mint; further, this is not an issue with any non-Mozilla software. This ONLY began when Linux kernel 6.8.0.50 came out, and persisted with 6.8.0.51. Additionally, the fact that the problem was ALMOST fixed between Firefox 133.0.0 and 133.0.3 tells me it is absolutely a Firefox issue. It is DEFINITELY not a Linux Mint issue, save for the fact that the Mint repositories only had version 133.0.0 at the time of the 6.8.0.50 update--which has been remedied since.
It could be a kernel issue MAYBE, but if that is the case, then ONLY Mozilla (and yes, Thunderbird is in this role as well, having the exact same problem but far less frequently) doesn't play well with this kernel.
I can second that this issue has occurred with someone else, my Masters advisor; she has had to stop using Firefox entirely in Linux, as she has the exact same issue, but in Ubuntu.
Comment 6•2 months ago
•
|
||
There aren't any meaningful changes between 133.0.0 and 133.0.3 that would affect Firefox on Linux.
You can see the list here: https://www.mozilla.org/en-US/firefox/133.0.3/releasenotes/
I also see a change to drag and drop timeouts (that was too insignificant to go in the release notes), but that's about as far removed from your problem as possible.
Your problem really sounds like the Linux kernel update has broken your video driver, so that would be my best guess. As to why you're only observing it on Firefox: it's likely one of the few programs that you are running that does anything beyond the absolute basics with that driver. So Firefox can easily provoke an existing or new bug in that driver. Obviously we can't fix this on the Firefox side, but it may be possible to work around this, for example by disabling all graphics acceleration, until you can get a fixed driver or kernel. As Thinker pointed out, you'll want to file an issue on the Mint and/or Ubuntu bugtrackers.
I assume your advisor is likely running the exact same graphics card and driver - Mint just repackages Ubuntu so it would have the exact same bug indeed.
Can you attach your about:support to this bug? Next, you may want to look in the system journal to see if there's any kernel errors logged when the machine hangs. (journalctl is your friend here)
As a first step, try running in Safe Mode (Troubleshoot Mode), this will disable all advanced use of the video driver. If this prevents the problem from occurring, we've more or less confirmed the issue: https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode
The fact that you need to do a fsck and repair on reboot further reinforces the suspicion this is a kernel and driver bug: application packages like Firefox have in no way the ability or access rights to the disk that would allow such damage.
I should've known not to submit a bug report to an open-sores project, much less one by Mozilla. Fact is, Firefox has been a problematic program for me for years, and not just in Linux; it crashes on one of my Windows machines multiple times a day, to the point that I've learned the lesson to do literally any and all work intended to be done in the browser, outside of it first, because Firefox WILL crash and burn, taking all that work with it.
But no, can't be us, can't be OUR program.
Firefox can't cause that kind of damage to the OS? Then ignore that part of my report.
No, there are no kernel errors when this happens. Nor are there any reports from anything on the system.
I provided the information about my advisor to illustrate that on her entirely different machine, which yes is running a similar operating system, the exact same problem is occurring--because to me, that illustrates that the problem, which in her case was ALSO isolated to Mozilla products, is CLEARLY in the Mozilla library somewhere.
I've used Troubleshoot Mode before, because wouldn't you know it, Firefox and Thunderbird also have extreme difficulty playing with Fluxbox, my window manager of choice. The claim made at the time was, "Firefox makes the system call correctly, it's Fluxbox that must be in error," making it abundantly obvious that no attempt was going to be made to fix THAT error of yours, either.
Go ahead and close this bug report then, y'all have no intention to address the issue, that much is clear. I'll just have to look elsewhere, for software that doesn't break.
Updated•2 months ago
|
Comment 8•2 months ago
|
||
Note it will be hard to diagnose this further without actionable information.
- Can you attach your
about:support
to this bug? - Does Troubleshoot Mode resolve the issue or not?
- If there are other users with an identical issue yet completely different hardware, would it be possible to obtain their
about:support
?
I'm seeing >500k users on 6.8.0-50, spread across Intel, AMD and NVIDIA graphics, but no other reports of this so far. Based on this, marking as S4 for now.
it crashes on one of my Windows machines multiple times a day
Can you file a separate bug, go to about:crashes
and attach some of the reports?
Reporter | ||
Comment 10•2 months ago
|
||
And for the other two items:
- No, no it does not. It seemed to at first, but indeed it does continue locking up. For the record, Google Chrome does not have this issue, even testing on the exact same websites, with every tab active. It is, indeed, JUST Firefox that does this.
- I will see if I can get her about:support data as well; indeed, my understanding is that it is an identical issue, but I would be EXTREMELY surprised if this person had the same hardware I do.
Comment 11•2 months ago
|
||
- My about:support is thus:
The file is empty - all the fields with information are stripped:
Application Basics
------------------
Name:
Version:
Build ID:
Distribution ID:
Update Channel:
User Agent:
...
Reporter | ||
Comment 12•2 months ago
|
||
Description
•