crash in EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER (Firefox for Desktop only)
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr45 | --- | wontfix |
| firefox-esr52 | --- | wontfix |
| firefox53 | --- | wontfix |
| firefox-esr115 | --- | affected |
| firefox54 | --- | wontfix |
| firefox55 | - | wontfix |
| firefox56 | --- | wontfix |
| firefox57 | --- | wontfix |
| firefox59 | --- | wontfix |
| firefox60 | --- | wontfix |
| firefox61 | --- | wontfix |
| firefox122 | --- | affected |
| firefox123 | --- | affected |
| firefox124 | --- | affected |
People
(Reporter: skywalker333, Unassigned)
References
(Depends on 2 open bugs)
Details
(4 keywords, Whiteboard: [tbbird crash])
Crash Data
|
Reporter | |
Comment 1•8 years ago
|
||
|
|
Reporter | |
Comment 2•8 years ago
|
||
|
||
Updated•8 years ago
|
|
|
Reporter | |
Updated•8 years ago
|
|
|
Reporter | |
Comment 3•8 years ago
|
||
|
|
Reporter | |
Comment 4•8 years ago
|
||
|
|
Reporter | |
Comment 5•8 years ago
|
||
|
||
Comment 6•8 years ago
|
||
|
|
Reporter | |
Comment 7•8 years ago
|
||
|
|
||
Comment 8•8 years ago
|
||
|
|
||
Comment 9•8 years ago
|
||
|
|
||
Comment 10•8 years ago
|
||
|
||
Comment 11•8 years ago
|
||
|
||
Comment 12•8 years ago
|
||
|
|
||
Comment 14•8 years ago
|
||
|
|
||
Comment 15•8 years ago
|
||
|
||
Comment 16•8 years ago
|
||
|
|
||
Comment 17•8 years ago
|
||
|
|
||
Comment 18•8 years ago
|
||
|
|
||
Comment 19•8 years ago
|
||
|
|
||
Comment 20•8 years ago
|
||
|
|
||
Updated•8 years ago
|
|
||
Comment 21•7 years ago
|
||
|
||
Comment 22•7 years ago
|
||
|
||
Comment 23•7 years ago
|
||
|
|
Reporter | |
Comment 24•7 years ago
|
||
|
|
||
Comment 25•7 years ago
|
||
|
|
||
Comment 26•7 years ago
|
||
|
|
||
Comment 27•7 years ago
|
||
|
|
||
Comment 28•7 years ago
|
||
|
|
||
Comment 29•7 years ago
|
||
|
|
||
Updated•7 years ago
|
|
||
Updated•7 years ago
|
|
||
Comment 30•7 years ago
|
||
|
|
Reporter | |
Comment 31•7 years ago
|
||
|
|
||
Comment 32•7 years ago
|
||
|
|
||
Comment 33•7 years ago
|
||
|
|
Reporter | |
Updated•7 years ago
|
|
||
Comment 34•7 years ago
|
||
|
|
Reporter | |
Comment 35•7 years ago
|
||
|
||
Comment 37•7 years ago
|
||
|
||
Updated•7 years ago
|
|
||
Comment 46•5 years ago
|
||
This is still happening in current Firefox versions, even for completely blank profiles, with a brand new reinstallation of Firefox.
Definitely not an OOM issue for me.
I'd also like to note that Firefox crashed on me 150+ times without any crash report before it produced a ERROR_NO_MINIDUMP_HEADER crash dump once. While that might not be the case for everyone, it could mean there's thousands more crashes than reported.
If it helps, I can give you about 45 Windows Error Report ids or .wer files. Some of them sent hundreds of megabytes to microsoft servers, there's bound to be something useful there.
|
||
Comment 47•5 years ago
|
||
.wer files are not very useful unfortunately but if you could provide me with a minidump collected locally via WER that would help a lot. To do so you need to add a registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps) and then when Firefox crashes look for the minidump under C:\Users\<username>\AppData\Local\CrashDumps. You can find more info about this here: Collecting User-Mode Dumps.
Send me the minidump directly via e-mail, do not attach it to this bug as it might contain privacy-sensitive information.
|
||
Comment 48•4 years ago
|
||
It's been a while here - Gabriele, is there actionable work we can do here? It looks like things have substantially improved since 3 months ago but crash volume is still non-trivial.
|
|
||
Comment 49•4 years ago
|
||
Yes, I would like to add some error reporting to the code that generates minidumps so that we can track the root causes of the failures. Unfortunately I've got my hands full ATM and I don't think I'll be able to look into it before next month. I'll file a bug that blocks this one so I don't forget.
|
|
||
Comment 50•3 years ago
|
||
This is a signature change caused by the new stack walker. BTW a quick glance at the remaining volume of crashes on desktop points to OOMs.
|
||
Updated•3 years ago
|
|
||
Comment 53•2 years ago
|
||
Hey gsvelto, what's a good Product :: Component for this bug?
|
|
||
Comment 54•2 years ago
|
||
This definitely belongs to crash reporting
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 56•2 years ago
|
||
This bug makes Firefox crash with 100% reproducibility on many websites, in particular major ones, such as https://facebook.com/ and https://www.adobe.com/
|
|
||
Comment 57•2 years ago
|
||
(In reply to Vincent Lefevre from comment #56)
This bug makes Firefox crash with 100% reproducibility on many websites, in particular major ones, such as https://facebook.com/ and https://www.adobe.com/
This isn't reproducible for us, and the crashes have no information... Gabriele, is there some way we can get more info from Vincent given it's crashing 100% of the time for him?
|
|
||
Comment 58•2 years ago
|
||
I've just tried again the same tests but with an access to the machine via ssh, thus with an X server running on a different machine, and Firefox doesn't crash in such a case. In short, the crash occurs only on some particular hardware and only locally. So the cause of the crash could be some form of race condition, or perhaps Firefox runs different code in this case.
|
|
||
Comment 59•2 years ago
|
||
(In reply to Vincent Lefevre from comment #58)
I've just tried again the same tests but with an access to the machine via ssh, thus with an X server running on a different machine, and Firefox doesn't crash in such a case. In short, the crash occurs only on some particular hardware and only locally. So the cause of the crash could be some form of race condition, or perhaps Firefox runs different code in this case.
It's odd to get a crash without a minidump but it can happen if some form of external sandboxing (or kernel security module) is used, as those can prevent the crash report from accessing /proc and thus generating the minidump. Could this machine be using something like that? Additionally the crash in bug 1803899 comment 5 shows that you're using a closed-source Nvidia driver on the machine. They're often a source of problems so that might also be the culprit.
|
|
||
Comment 60•2 years ago
|
||
I'm using firejail (as I've done for several years) with the firefox profile. Even if I use --ignore='include disable-proc.inc' to fully allow /proc, I get the same behavior (crash without a crash report) with both FF 107 and Nightly.
And I'm using the Nvidia driver because the nouveau driver is too broken and the developers didn't react to my bug reports. This is a possible culprit as a new version appeared yesterday fixing security issues and Debian's changelog says "Improved compatibility with recent Linux kernels". So I'm going to do a few tests, then upgrade.
|
|
||
Comment 61•2 years ago
|
||
BTW, among the URLs that make Firefox crash, there's https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles (but I cannot reproduce the crash if I first download the HTML file and open it locally with the "file:" URL scheme).
|
|
||
Comment 62•2 years ago
|
||
The buggy Nvidia driver was the cause of the crashes. And when I rebooted, the display manager couldn't even start (apparently because the X server was failing) and the Linux virtual terminals didn't work either, though I had no issues with the reboot on November 30, after the latest updates. I had to do the upgrade via ssh from my phone.
Moreover, I inspected the journalctl logs and saw lots of lines like
Dec 02 19:53:18 zira audit[1440595]: SECCOMP auid=1000 uid=1000 gid=1000 ses=2 subj=firejail-default pid=1440595 comm="CanvasRenderer" exe="/usr/lib/firefox/firefox" sig=0 arch=c000003e syscall=101 compat=0 ip=0x7f22b960f275 code=0x50000
and
Dec 02 19:53:18 zira kernel: audit: type=1326 audit(1670007198.987:31): auid=1000 uid=1000 gid=1000 ses=2 subj=firejail-default pid=1440595 comm="CanvasRenderer" exe="/usr/lib/firefox/firefox" sig=0 arch=c000003e syscall=101 compat=0 ip=0x7f22b960f275 code=0x50000
starting at this date (nothing like that before, since the beginning of my logs on 2021-04-24). I suppose that this corresponded to the crashes (or was related to them).
Now, after the upgrade, everything is fine.
|
||
Comment 63•2 years ago
|
||
bp-a67c304a-b335-4718-8a5a-858970230107 Windows 10. It had been running for two weeks, but that's not unusual.
In addons manager I had just disabled adblock plus add-on, and then in addons manager was searching for ublock origin
|
||
Comment 64•2 years ago
|
||
Just a note to say that the absence of information in the crash reports is (predictably) causing multiple issues across multiple OS and packaging types to be conflated. For example, my crashes on Linux from a Flatpak installation are linked to this thread discussing Windows 10.
I can tell you that even in the Flatpak distribution, which should have updates disabled, Firefox is still downloading something and so randomly corrupting itself. This manifests as tabs suddenly start to crash and then either cannot be reloaded or crash again after e.g. scrolling. Sometimes the browser closes completely without warning and then cannot be relaunched until the installation has been repaired.
|
|
||
Comment 65•2 years ago
|
||
EMPTY: no frame data available; MissingThreadList #40 crash for Thunderdbird 102.9.0, all linux
|
|
||
Comment 66•2 years ago
|
||
Once again, Firefox randomly closes itself (all tabs and windows are lost) due to self-corruption and cannot be relaunched until the installations is repaired:
$ flatpak repair --user
[19/213] Verifying flathub:app/org.mozilla.firefox/x86_64/stable…
fsck content object 266baf34571baf031d5968384f75582f0c1008d90663d6bcdd53b24613acad06: Corrupted file object; checksum expected='266baf34571baf031d5968384f75582f0c1008d90663d6bcdd53b24613acad06' actual='b47e27f3e9f5ff86828ef5d6f112922e45d49ffd9f29f34fec7f97e89f85fceb', deleting object
Marking commit as partial: efba60722ae51de8ec2d8b933f76f3f850f0e38f90325dc16c48c1581c4a530c
Deleting ref flathub:app/org.mozilla.firefox/x86_64/stable due to invalid objects
|
|
||
Comment 67•2 years ago
|
||
(In reply to womagrid from comment #66)
Once again, Firefox randomly closes itself (all tabs and windows are lost) due to self-corruption and cannot be relaunched until the installations is repaired:
$ flatpak repair --user [19/213] Verifying flathub:app/org.mozilla.firefox/x86_64/stable… fsck content object 266baf34571baf031d5968384f75582f0c1008d90663d6bcdd53b24613acad06: Corrupted file object; checksum expected='266baf34571baf031d5968384f75582f0c1008d90663d6bcdd53b24613acad06' actual='b47e27f3e9f5ff86828ef5d6f112922e45d49ffd9f29f34fec7f97e89f85fceb', deleting object Marking commit as partial: efba60722ae51de8ec2d8b933f76f3f850f0e38f90325dc16c48c1581c4a530c Deleting ref flathub:app/org.mozilla.firefox/x86_64/stable due to invalid objects
This should probably be filed as a separate bug, and marked as blocking bug 1278719. I'm not personally familiar with flatpak but it would also be useful if you could check a directory diff between a functional install and the broken one that flatpak is "repairing" (whatever that means). "Downloading something" is not really much to go on - Firefox downloads lots of stuff while running (not least stuff you tell it to download), but off-hand I can't think of anything that would normally end up in the application directory (neither for flatpaks nor anything else). It should all go either where the user tells it to put things, or in the user's profile directory, which isn't part of the flatpak itself. So I've no idea what the thing is that we could be downloading that is "corrupting" anything.
|
|
||
Comment 68•2 years ago
|
||
Predictable response, but the same thing used to happen with the .deb distribution. Yes, I'm sure that you would like more information, but I simply don't have it. This has been happening for years.
|
|
||
Comment 69•2 years ago
|
||
(In reply to womagrid from comment #68)
Predictable response, but the same thing used to happen with the .deb distribution. Yes, I'm sure that you would like more information, but I simply don't have it. This has been happening for years.
Is it not possible for you to zip up (or tar.gz or w/e) the "working" application directory and the "broken" version of the same app, and then compare the two?
|
|
||
Comment 70•2 years ago
|
||
If it happens again, I will try to remember to do that. Usually I am in the middle of something critical, so the priority is to get the browser working again ASAP. Fixing it via re-installation has become habitual at this point.
|
||
Comment 71•2 years ago
|
||
God, this has been affecting me 10+ times a day for the past week. Never happened before.
I'm on Linux Flatpak, version 112.0.2, here's the latest crash report: https://crash-stats.mozilla.org/report/index/98b86f9e-75a3-4387-ab24-8d2860230502
Do not mind the incorrect version number, that's because of issue https://bugzilla.mozilla.org/show_bug.cgi?id=1653852 ...
|
|
||
Comment 72•1 years ago
|
||
Happened again. Firefox crashed suddenly and was unable to relaunch.
The Flatpak installation was again corrupted:
$ flatpak repair --user
Working on the user installation at /home/mark/.local/share/flatpak
[27/217] Verifying flathub:app/org.mozilla.firefox/x86_64/stable…
fsck content object f06bd7446ea0505a4c5258712fc3770bf8acc3f6e3054884e90e0517ba537b09: Corrupted file object; checksum expected='f06bd7446ea0505a4c5258712fc3770bf8acc3f6e3054884e90e0517ba537b09' actual='13c538c0873250c985bb314ad1339347a43e040bbd7f63353fae09fe8c2e0ff8', deleting object
Marking commit as partial: af68d26ccf4fa74ecb9d718196388db990729211618ee0b34272f4d4b9328f06
Deleting ref flathub:app/org.mozilla.firefox/x86_64/stable due to invalid objects
[217/217] Verifying flathub:runtime/io.github.celluloid_player.Celluloid.Locale/x86_64/stable…
Checking remotes...
Pruning objects
Erasing .removed
Reinstalling removed refs
Installing app/org.mozilla.firefox/x86_64/stable
Diff against the backup I took before reinstallation shows that libxul.so was corrupted:
$ diff -ruw ~/Documents/org.mozilla.firefox/x86_64/stable/af68d26ccf4fa74ecb9d718196388db990729211618ee0b34272f4d4b9328f06/ ~/.local/share/flatpak/app/org.mozilla.firefox/x86_64/stable/af68d26ccf4fa74ecb9d718196388db990729211618ee0b34272f4d4b9328f06/ 2>&1 | grep -v xpi
Binary files /home/mark/Documents/org.mozilla.firefox/x86_64/stable/af68d26ccf4fa74ecb9d718196388db990729211618ee0b34272f4d4b9328f06/files/lib/firefox/libxul.so and /home/mark/.local/share/flatpak/app/org.mozilla.firefox/x86_64/stable/af68d26ccf4fa74ecb9d718196388db990729211618ee0b34272f4d4b9328f06/files/lib/firefox/libxul.so differ
|
|
||
Comment 73•1 years ago
|
||
Looks as though only 3 bytes changed...
--- /dev/fd/63 2023-06-15 11:18:12.340719059 +0100
+++ /dev/fd/62 2023-06-15 11:18:12.340719059 +0100
@@ -5759948,15 +5759948,15 @@
057e3cb0: 7fcd 4d8b 1424 498b 7c24 084d 8b46 084d ..M..$I.|$.M.F.M
057e3cc0: 8b5f 084d 8b0e 4939 fb0f 84e0 0100 0048 ._.M..I9.......H
057e3cd0: 39da 0f84 ec00 0000 48ff cf4d 8b32 418b 9.......H..M.2A.
-057e3ce0: 3648 39f7 7363 4883 02f0 498d 40fe 49c1 6H9.scH...I.@.I.
+057e3ce0: 3648 39f7 7363 4883 c2f0 498d 40fe 49c1 6H9.scH...I.@.I.
057e3cf0: e004 4983 c0e8 4989 fc49 c1e4 048b 6a08 ..I...I..I....j.
057e3d00: 488d 4801 4d8b 3941 8b37 433b 6c26 107c H.H.M.9A.7C;l&.|
057e3d10: 4548 39f1 0f83 cf00 0000 8b4a 0843 894c EH9........J.C.L
-057e3d20: 0718 488b 0a4b 894c 4710 4839 da0f 8491 ..H..K.LG.H9....
+057e3d20: 0718 488b 0a4b 894c 0710 4839 da0f 8491 ..H..K.L..H9....
057e3d30: 0000 0048 83c2 f04d 8b32 418b 3648 ffc8 ...H...M.2A.6H..
057e3d40: 4983 c0f0 4839 f772 ade8 52da e1fa 4889 I...H9.r..R...H.
057e3d50: dae9 69ff ffff 4839 f10f 838a 0000 004b ..i...H9.......K
-057e3d60: 8d0c 2648 83c1 088b 3108 4389 7407 1848 ..&H....1.C.t..H
+057e3d60: 8d0c 2648 83c1 088b 7108 4389 7407 1848 ..&H....q.C.t..H
057e3d70: 8b09 4b89 4c07 1049 39fb 0f84 8701 0000 ..K.L..I9.......
057e3d80: 48ff cfeb b248 01d9 48f7 d948 85c9 7e34 H....H..H..H..~4
057e3d90: 48c1 e904 48ff c148 8b02 8b30 4839 f773 H...H..H...0H9.s
|
|
||
Comment 74•1 years ago
|
||
(In reply to womagrid from comment #73)
Thanks for the update, this is useful info!
Looks as though only 3 bytes changed...
--- /dev/fd/63 2023-06-15 11:18:12.340719059 +0100 +++ /dev/fd/62 2023-06-15 11:18:12.340719059 +0100 @@ -5759948,15 +5759948,15 @@ 057e3cb0: 7fcd 4d8b 1424 498b 7c24 084d 8b46 084d ..M..$I.|$.M.F.M 057e3cc0: 8b5f 084d 8b0e 4939 fb0f 84e0 0100 0048 ._.M..I9.......H 057e3cd0: 39da 0f84 ec00 0000 48ff cf4d 8b32 418b 9.......H..M.2A. -057e3ce0: 3648 39f7 7363 4883 02f0 498d 40fe 49c1 6H9.scH...I.@.I. +057e3ce0: 3648 39f7 7363 4883 c2f0 498d 40fe 49c1 6H9.scH...I.@.I. 057e3cf0: e004 4983 c0e8 4989 fc49 c1e4 048b 6a08 ..I...I..I....j. 057e3d00: 488d 4801 4d8b 3941 8b37 433b 6c26 107c H.H.M.9A.7C;l&.| 057e3d10: 4548 39f1 0f83 cf00 0000 8b4a 0843 894c EH9........J.C.L -057e3d20: 0718 488b 0a4b 894c 4710 4839 da0f 8491 ..H..K.LG.H9.... +057e3d20: 0718 488b 0a4b 894c 0710 4839 da0f 8491 ..H..K.L..H9.... 057e3d30: 0000 0048 83c2 f04d 8b32 418b 3648 ffc8 ...H...M.2A.6H.. 057e3d40: 4983 c0f0 4839 f772 ade8 52da e1fa 4889 I...H9.r..R...H. 057e3d50: dae9 69ff ffff 4839 f10f 838a 0000 004b ..i...H9.......K -057e3d60: 8d0c 2648 83c1 088b 3108 4389 7407 1848 ..&H....1.C.t..H +057e3d60: 8d0c 2648 83c1 088b 7108 4389 7407 1848 ..&H....q.C.t..H 057e3d70: 8b09 4b89 4c07 1049 39fb 0f84 8701 0000 ..K.L..I9....... 057e3d80: 48ff cfeb b248 01d9 48f7 d948 85c9 7e34 H....H..H..H..~4 057e3d90: 48c1 e904 48ff c148 8b02 8b30 4839 f773 H...H..H...0H9.s
And only 4 bits, if my counting is correct.
This should definitely be a separate bug at this point - it would be useful to understand if there is a chance there's a hardware issue, what the permissions on the directory containing this file (and the file itself) are, and if it's possible to monitor what is making changes to it (does flatpak/flathub/whatever do any updating itself?)... because it shouldn't be Firefox. Changing only 4 bits only on the library file doesn't seem like it really matches the earlier hypothesis that "Firefox is still downloading something and so randomly corrupting itself"...
|
|
||
Comment 75•1 years ago
|
||
Nothing in the system log related to Flatpak until I did the repair.
I also wondered about hardware issues, but I would expect many more occurrences, and not only Firefox to be affected (it's always Firefox).
|
|
||
Comment 76•1 years ago
|
||
A bit being flipped always at the same spot might be an indication of an issue with the system's memory. Did you run a diagnostic with a tool like memtest86+ to verify if your machine's memory is working properly? If you didn't consider trying it.
|
||
Comment 77•1 year ago
|
||
Can you try marking the file as unwritable by anyone, before corruption? (chmod a-r ...)
I don't know this works with flatpacks, but probably it does...
@gsvelto - This would be on disk, though, not in memory I assume. But a memtest wouldn't hurt, for sure.
The only other thing I can think of is some virus/malware that's trying to apply a hack to the firefox libxul, but was intended for a different version...
This may help a lot in tracking the corruption down:
inotifywait --event modify <libxul path>
You could also look at https://emcrisostomo.github.io/fswatch/
|
|
||
Comment 78•1 year ago
|
||
(In reply to Randell Jesup [:jesup] (needinfo me) from comment #77)
@gsvelto - This would be on disk, though, not in memory I assume. But a memtest wouldn't hurt, for sure.
My reasoning is that the file could have been corrupted when the data was in the page cache, and a page with the broken data was then flushed to disk.
|
||
Comment 79•1 year ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:gsvelto, since the bug has high severity and recent activity, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
||
Updated•10 months ago
|
|
|
||
Updated•5 months ago
|
| Comment hidden (obsolete) |
|
|
||
Comment 81•2 months ago
|
||
Still occurs with FF 131:
https://crash-stats.mozilla.org/report/index/76a14fa3-7cb5-4dbf-a051-d62110241007
Firefox 131.0 Crash Report [@ EMPTY: no frame data available; EmptyMinidump ]
|
|
||
Comment 82•2 months ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #59)
It's odd to get a crash without a minidump but it can happen if some form of external sandboxing (or kernel security module) is used, as those can prevent the crash report from accessing
/procand thus generating the minidump.
If Firefox cannot access something, this fact (with the precise resource and error) should be written in the crash report so that the user can know and possibly relax the restrictions.
|
|
||
Comment 83•2 months ago
|
||
(In reply to Vincent Lefevre from comment #82)
If Firefox cannot access something, this fact (with the precise resource and error) should be written in the crash report so that the user can know and possibly relax the restrictions.
Yes, we're working on that, see the issue where we're tracking this.
| Comment hidden (obsolete) |
| Comment hidden (obsolete) |
| Comment hidden (obsolete) |
|
|
||
Comment 87•2 months ago
|
||
(In reply to Denis Müller [:Webworkr] from comment #85)
This bug report may be related to bug 1923605.
Bug 1923605 and all your crash-stats links are about Android, while the bug here is for desktop only (see the bug title).
|
||
Comment 88•2 months ago
|
||
(In reply to Vincent Lefevre from comment #87)
(In reply to Denis Müller [:Webworkr] from comment #85)
This bug report may be related to bug 1923605.
Bug 1923605 and all your crash-stats links are about Android, while the bug here is for desktop only (see the bug title).
I was already aware of the title "Desktop" of this bug report. Since the crash reports had always referred to this bug, I thought it might be helpful. Thanks for the feedback, I will spare us all further references in the future.
|
|
||
Comment 89•2 months ago
|
||
The Android bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1245570
Description
•