Closed Bug 441142 Opened 18 years ago Closed 1 year ago

improve error reporting when Crash Reporter fails with ErrorDumpFileMove=Couldn't move crash dump

Categories

(Toolkit :: Crash Reporting, enhancement)

Product:
Toolkit
Component:
Crash Reporting
Platform:
x86
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cerebro.alexiel, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.9 (like Gecko) (Debian) Build Identifier: When I start Firefox, it tries to recovers all my windows from my previous session but after some minutes (recovering takes a lots of time) it crashes complaining that it can't move the crash log. So I looked into my firefox profile directory, sorting files by modification date, I found "minidumps" wich contained several files. The content of the last "crash" is include further Reproducible: Always Steps to Reproduce: 1.start firefox 2.wait 3. Actual Results: Firefox close all windows and tabs and show a box saying that it can't move the crash log. Expected Results: Recover my session correctly Firefox was launched as root. I know, I know, it's BAD. And I use "Linux cerebro 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux" You can view log files at <http://www.uploading.com/files/URRQW9TC/Archive.tar.bz2.html>.
Do you have a breakpad id of the crash? http://kb.mozillazine.org/Breakpad
I don't have a breakpad id of the crash because the crashreporter did not work. I've started firefox again and it does not crashes anymore. However, I would like to send my minidumps manually (I think they can contain debug information). How to do that ? crashreporter --usage does not help me.
It happens again. If you want to see a snapshot of the error message, you can go to http://img384.imageshack.us/my.php?image=firefoxerrorjq7.png. But it's in french. The last sentence says "Details : Can't move the crash log" Where does the log supposed to be moved ? Can an appropriate 'chmod' on the right folder let crashreporter do its job ?
See for info on breakpad here: http://kb.mozillazine.org/Breakpad But are you using Firefox 2 or Firefox 3? You are using an official build from Mozilla, right?
reporter: Based on this bug's direction, let's focus on improving/fixing crash reporter. I think strace may actually be useful here (I generally do not recommend it, this is a special case, we need to know which system call is failing w/ what params why). you'll probably need to do: ./run-mozilla.sh `which sh` strace -f ./firefox-bin fwiw, here's the path to your code (thanks for the relatively good translation of the string, it saved me from using the l10n tree) http://mxr.mozilla.org/mozilla-central/search?string=move%20crash&find=crashreport http://mxr.mozilla.org/mozilla-central/search?string=ErrorDumpFileMove&find=crashreport http://mxr.mozilla.org/mozilla-central/search?string=ST_ERROR_DUMPFILEMOVE&find=crashreport http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter.cpp#276 http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter_linux.cpp#880 the code is fairly simple, it's just moving a file. strace will explain what's going wrong. you can *attach* the output from strace, or simply find the *one* line that says something like: rename(...) = E...
Component: Theme → Breakpad Integration
Product: Firefox → Toolkit
QA Contact: theme → breakpad.integration
Summary: Crash after opening a saved session with a lot of windows → Crash Reporter fails ErrorDumpFileMove=Couldn't move crash dump.
Version: unspecified → Trunk
It's trying to move it to ~/.mozilla/firefox/Crash Reports/pending .
On my mind, this error has appeared because I was root. I used to be a newbie and I thought that beeing root was easiest and less boring than typing 'w3lc0m3t0l1nux'. But now, I want to manage my system as an (good?) administrator, report bug, why not write some patches ... I guess logging as root every day has (more or less) damaged my computer. I don't think this error was only caused by Firefox or its components but by several mistakes (broken symbolic links, files and folders created and only writable by root ...etc). So I re-installed my debian and now I am 'alex' not 'root'. For the moment, no 'could'nt move crash log' problems. Of course, if this error occurs again, I will do what you said. Sorry for this bug wich is (maybe) not a bug. Sorry again and Thanks
it's a perfectly reasonable report. the error message should at least indicate the destination and the kind of problem (out of disk space, permissions, ...). Based on the kind of problem, it isn't a top priority, but I'd hope we'd accept a patch to improve the error reporting.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash Reporter fails ErrorDumpFileMove=Couldn't move crash dump. → improve error reporting when Crash Reporter fails with ErrorDumpFileMove=Couldn't move crash dump
Crashed again ^^ But 'breakpad' works and sends the crash dump. I will try ./run-mozilla.sh `which sh` and strace -f ./firefox-bin Note that if I stop the loading of some web pages, firefox doesn't crash. These pages contain flash movies and are long/high A memory bug ?
oops. thought-o, sorry i meant crashreporter-bin, not firefox-bin. anyway. for crash reports that are sent, just load about:crashes, and grab the incident id. file a new bug w/ the incident id and someone will help it find a place.
I could provide additional strace logs or crash dumps, if one could give me some directions. I'm using the nightly build (2008-10-08 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.1b1pre.en-US.linux-i686.tar.bz2 ) of firefox 3.1. The browser always (!) crashes when exiting. After the crash, the mentioned error dialog appears, "Couldn't move crash dump". But that message only appears when I'm using a profile with non-relative path, i.e. my ~/.mozilla/firefox/profiles.ini looks like [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=1 Path=abcde.default Default=1 [Profile1] Name=private IsRelative=0 Path=/mnt/crypt/.mozilla/firefox/def.private If starting minefield with the profile "private", the dialog "Couldn't move crash dump" appears. If starting minefield with the profile "default", the mozilla crash reporter opens as expected. Some tries tracking that down using "strace -e open" and "strace -e open,read,write" didn't give _me_ any clues what's going wrong (but I'm only scratching the surface). File permissions shouldn't be an issue here, the user I start the minefield with has all permissions on both dirs /home/user/.mozilla/firefox and /mnt/crypt/.mozilla/firefox. Please let me know if I could provide additional information on this issue. A working crash reporter is mandatory for helping improving firefox nightly builds...
Addition: It doesn't have to do with "relative path" vs. "absolute path", I checked that adding some more profiles. The message "Couldn't move crash dump" only appears if the profile with the absolute path resides in another filesystem. Erm. Did I mention I'm running linux with kernel 2.6.25.13?
Ted: Indeed, indeed, I'm sorry. So this bug, what is it about? The crash dump file can't be moved, the crash reporter says "Couldn't move crash dump", so that's perfectly allright (so it seems to me).
See comment 8.
Severity: normal → enhancement
Blocks: 506009
Severity: normal → S3

I just saw this (I believe for the first time). Firefox 106.0.3 on Ubuntu 22.10 using XFCE.
The observed behavior:

  1. Firefox went away unexpectedly (no crash report generated). The web sites loaded were sites I use regularly.
  2. Tried to start Firefox, got "Couldn't move crash dump".
  3. Tried to start Firefox again, got "Couldn't move crash dump".
  4. Rebooted and was able to start Firefox.

Comment .12 says the problem is related to multiple file systems, but this system only has one local file system (and the configuration hasn't changed since the last time a crash report was generated). There was a remote file system loaded, but no files from that system were opened inside Firefox, Firefox is installed locally, and the profiles and configuration are local.

This ought to be fixed in bug 506009.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
No longer blocks: 506009
Depends on: 506009
You need to log in before you can comment on or make changes to this bug.