Open Bug 1928839 Opened 1 year ago Updated 1 year ago

"Firefox had a problem and crashed. Unfortunately, the crash reporter is unable to submit a report for this crash."

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Version:
Firefox 132
Type:
defect

Tracking

()

People

(Reporter: celenity, Unassigned)

References

Details

Steps to reproduce:

When attempting to run Firefox 132 on Fedora 41, I'm getting the following error:

"Firefox had a problem and crashed. Unfortunately, the crash reporter is unable to submit a report for this crash.

Details: Failed to move /home/user/.mozilla/firefox/7mw9kpvj.default-release/minidumps/6154bd12-b919-5ee4-3ea2-874ac037813c.dmp to /home/user/.mozilla/firefox/Crash Reports/pending/6154bd12-b919-5ee4-3ea2-874ac037813c.dmp"

I don't see the 6154bd12-b919-5ee4-3ea2-874ac037813c.dmp in either /home/user/.mozilla/firefox/7mw9kpvj.default-release/minidumps/ or /home/user/.mozilla/firefox/Crash Reports/pending/, but I do see 6154bd12-b919-5ee4-3ea2-874ac037813c.extra in /home/user/.mozilla/firefox/7mw9kpvj.default-release/minidumps/, which has the following content:

{"AdapterDeviceID":"0x1e84","AdapterDriverVendor":"nvidia/unknown","AdapterDriverVersion":"565.57.1.0","AdapterVendorID":"0x10de","Add-ons":"formautofill%40mozilla.org:1.0.1,pictureinpicture%40mozilla.org:1.0.0,screenshots%40mozilla.org:39.0.1,webcompat%40mozilla.org:133.2.0","BackgroundTaskMode":"0","BuildID":"20241026095046","DesktopEnvironment":"gnome","DOMFissionEnabled":"0","DOMIPCEnabled":"0","EMCheckCompatibility":"true","HeadlessMode":"0","InstallTime":"1730580366","IsWayland":"1","LastStartupWasCrash":"1","MozCrashReason":"MOZ_CRASH(Unhandled exception)","Notes":"Fedora Linux 41 (Workstation Edition)FP(D00-L1000-W0000000-T01) ","ProductID":"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}","ProductName":"Firefox","ReleaseChannel":"release","SafeMode":"0","ServerURL":"https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=132.0&buildid=20241026095046","StartupCacheValid":"0","StartupCrash":"1","StartupTime":"1730589246","TelemetrySessionId":"8c955f2f-683f-4dad-b594-1c26e429cf3f","Vendor":"Mozilla","Version":"132.0","TotalPhysicalMemory":"16677265408","AvailablePhysicalMemory":"10247921664","AvailableVirtualMemory":"12886634496","AvailableSwapMemory":"8589930496","AvailablePageFile":"2049830912","TotalPageFile":"25267195904","CrashTime":"1730589246","UptimeTS":".56910302","SecondsSinceLastCrash":"30"}

Actual results:

Firefox doesn't start, and instead gives the error as described above.

Expected results:

Firefox should start without issue.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Crash Reporting' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Crash Reporting
Product: Firefox → Toolkit
See Also: → 1919769

The severity field is not set for this bug.
:gsvelto, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(gsvelto)
Flags: needinfo?(gsvelto)

CC'ing :afranchuk because this might be a corner-case of the new crash reporter client. I remember reviewing this code and that we have a fallback when failing to move the file, but I can't remember a scenario where we delete the file on both ends. That being said if we encounter an irrecoverable failure when moving the minidump we should clean up the .extra file.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true

If you can provide /home/user/.mozilla/firefox/Crash Reports/submit.log, that would be very helpful! Assuming it hasn't been overwritten (we should probably change that to some sort of rolling log).

Flags: needinfo?(disarray_fraction400)

We may want to change the UI display to show all frames of the Error too (there should be additional context about why it failed, but we only display the first error message).

See Also: → 506009

:afranchuk,

I don't see a submit.log file located at /home/user/.mozilla/firefox/Crash Reports/submit.log. Is there anywhere else it might be, or a different name it might have? More than happy to help however I can.

For an update, I ended up resetting my PC, and now stable Firefox actually works fine. I'm not sure what fixed it?

However, I also have Firefox Developer Edition installed, which is still having the issue I described above. I wonder if Developer Edition's submit.log file is located elsewhere? If it's of any help, I'm using this COPR build.

Flags: needinfo?(disarray_fraction400)

Hmm, it should always be there (if there was any log output written). If it got to that error it should have written some warnings to the log.

Ah, but I just realized by default it only logs errors, not warnings. I think it would be appropriate (and helpful) to change that default to include warnings.

If you can reproduce the crash, please run Firefox (or developer edition if that's what you can get to crash) with MOZ_CRASHREPORTER_LOG=debug set in the environment. That should definitely cause the log to appear if all else is functioning as expected.

The error UI immediately logs the error message, so the log level doesn't explain why you don't have the log file.

It just occurred to me that perhaps submit.log wasn't written for the same reason the original file move/copy failed, since that was also trying to copy to the same subdirectory. Out of disk space? Are there separate partitions/filesystems involved?

When bug 1938340 lands, all information about the error will be displayed in the error dialog, which will help us figure out what's going on here.

Depends on: 1938340

Apologies for the late response here! Somehow I completely missed this.

Out of disk space? Are there separate partitions/filesystems involved?

No to both. Plenty of storage, and only 1 partition/filesystem.

Thanks for following up. Now that bug 1938340 has landed, we should be able to get a lot more detailed information when this occurs again in the future (in the log and in the error dialog itself).

Sounds good, I'll report back next time I encounter this.

OK :afranchuk, I've just encountered this again; running Firefox 137 on Fedora 41.

The exact message I'm seeing is as follows:

Firefox Crash Reporter
Firefox had a problem and crashed. Unfortunately, the crash reporter is unable to submit a report for this crash.

Details:
Failed to move ⁨/tmp//52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩ to ⁨/home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩

Caused by:
    No such file or directory (os error 2)

This time, I do have a submit.log located at /home/user/.mozilla/firefox/Crash Reports/submit.log, and it has the following contents:

[WARN  crashreporter] minidump analyzer failed: while reading minidump
[WARN  crashreporter::config] failed to move /tmp//52df58db-11ab-40bf-7c01-124c02e8201f.dmp to /home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp: Invalid cross-device link (os error 18)
[ERROR crashreporter] exiting with error: Failed to move ⁨/tmp//52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩ to ⁨/home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩: No such file or directory (os error 2)

I don't see 52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩ at either ⁨/tmp/52df58db-11ab-40bf-7c01-124c02e8201f.dmp or /home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp.

I did notice that the error message and log above seem to have 2 slashes after tmp: /tmp**//**52df58db-11ab-40bf-7c01-124c02e8201f.dmp⁩ - is that intended, and could it be part of the problem here?

The two slashes should be inconsequential. If any errors occur, no changes to the filesystem are made. So if you can't find the listed file in /tmp, something bad must have happened when generating the minidump file. I just checked our exception handler code and it appears that we still invoke the crash reporter if the minidump generator reports a failure, so that's at least part of the problem here. I'm not sure if another course of action is appropriate, because either way we should make the user aware that the program has crashed and give an option to restart. I think this particular case should be improved so that rather than a consequential error being shown in the crash reporter, we at least say something more accurate, like "Firefox crashed, however there was an error capturing the crash state, so we cannot send a crash report at this time." :gsvelto any idea of the history here? I went back in the history of the code and it's always had that behavior.

It's also possible (however probably unlikely) that we generate it but some other program is deleting it.

How did you install firefox? I see that the fedora repos only have firefox 135 as of today.

Flags: needinfo?(gsvelto)

I'd be in favor of special-casing the case where the crash reporter is handed a path to a minidump but then doesn't find it. We should at least let the user restart/quit without the ability to submit the report (and use telemetry to record the case as we'd like to keep an eye on that happening too often).

Flags: needinfo?(gsvelto)

[WARN crashreporter::config] failed to move /tmp//52df58db-11ab-40bf-7c01-124c02e8201f.dmp to /home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp: Invalid cross-device link (os error 18)

The error message indicates that / and /tmp are on the different filesystems. But it contradicts with reporter's comment #12.

(In reply to Masatoshi Kimura [:emk] from comment #18)

[WARN crashreporter::config] failed to move /tmp//52df58db-11ab-40bf-7c01-124c02e8201f.dmp to /home/user/.mozilla/firefox/Crash Reports/pending/52df58db-11ab-40bf-7c01-124c02e8201f.dmp: Invalid cross-device link (os error 18)

The error message indicates that / and /tmp are on the different filesystems. But it contradicts with reporter's comment #12.

The reason that's only a warning is because if it fails to move, it will fall back to copying the file (that is to say, it should be okay even with that error). Now I'm wondering what the behavior is if you try to move a non-existent file to another filesystem (i.e., does it first check whether the filesystems are different and fail there, or will it first check whether the file exists). But yeah, that does seem to contradict comment #12.

I just checked, and glibc's rename does in fact check the filesystem before checking whether a file exists.

Oh of course, / and /tmp are different filesystems (/tmp is tmpfs). So that error makes sense.

See Also: → 1959875
You need to log in before you can comment on or make changes to this bug.