A friend of mine is crashing repeatedly and for some reason his crash reports aren't getting processed correctly. Here are two of them: http://crash-stats.mozilla.com/report/pending/8b34b75f-930a-4add-91a7-729a72100713 http://crash-stats.mozilla.com/report/pending/6bf10bb3-939a-47cb-8cc1-312b52100713 They keep being pending but sometimes when loading I see the following message: Queue Info ID 8b34b75f-930a-4add-91a7-729a72100713 Time Queued 2010-07-13 23:21:58.985348 Time Started 2010-07-13 23:22:04.299658 Message /home/processor/stackwalk/bin/stackwalk.sh returned no header lines for reportid: 144863348; No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed; /home/processor/stackwalk/bin/stackwalk.sh returned no frame lines for reportid: 144863348; /home/processor/stackwalk/bin/stackwalk.sh failed with return code 1 when processing dump 8b34b75f-930a-4add-91a7-729a72100713
We have a couple of other bugs on file about crash reports that have malformed minidumps and thus can't be processed, we have not determined a root cause yet. Even if they fail to process, you should be able to get to a report page, though, it should just inform you that the dump failed to process. (Plus, if you can get to the report page, we could download the minidump and look at it.) What platform is your friend on?
(In reply to comment #1) > What platform is your friend on? Windows 7 64-bit (though I believe he is using a 32-bit build)
Ok. (We don't have crash reporting enabled on the x64 builds yet.) I know crash reporting works ok on 32-bit builds there, so it must be whatever specific crash he's hitting. I think there are some Flash crashes that can screw us up so badly that we can't write a useful dump. Is he using 3.6.6?
I'm getting the "Oh Noes! This archived report could not be located." error for those (that's the same thing I'm seeing in bug 572174). I wonder if we need an explicit bug on bug 572174 comment 5?
I have such a crash report on the latest nightly, amd64. http://crash-stats.mozilla.com/report/pending/24893e83-921a-4638-a928-287e12101024 "/home/processor/stackwalk/bin/stackwalk.sh returned no header lines for reportid: 179463087; No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed; /home/processor/stackwalk/bin/stackwalk.sh returned no frame lines for reportid: 179463087; /home/processor/stackwalk/bin/stackwalk.sh failed with return code 1 when processing dump 24893e83-921a-4638-a928-287e12101024"
I have a friend who's seeing this problem with the 4.0 RC on 32 bit Win 7. She's crashing several times a day. About 25% of her crashes fail to submit at all, and of those that do, the majority just give the "Oh Noes!" message. For example: http://crash-stats.mozilla.com/report/index/bp-0fe708e2-e6e3-4bbd-9892-9c2252110318 Once when trying to load that particular crash I got the following message: Queue Info ID 0fe708e2-e6e3-4bbd-9892-9c2252110318 Time Queued 2011-03-19 17:17:32.297374 Time Started 2011-03-19 17:17:34.459179 Message INFO: This record is a replacement for a previous record with the same uuid; /data/socorro/stackwalk/bin/stackwalk.sh returned no header lines for reportid: 232590548; No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed; /data/socorro/stackwalk/bin/stackwalk.sh returned no frame lines for reportid: 232590548; /data/socorro/stackwalk/bin/stackwalk.sh failed with return code 1 when processing dump 0fe708e2-e6e3-4bbd-9892-9c2252110318
That generally means that the minidump was empty, which can occur for OOM crashes or heap corruption crashes.
I'm not sure which bit of what I said you're referring to there. Also can't we preallocate enough memory for the crash reporter to use so that it can submit a non-empty dump on OOM so that we can distinguish OOM crashes from other types of crash?
The "Oh Noes!" message, with the bit you pasted below, means we got a malformed minidump (usually zero bytes, if it says "returned no header lines". We use the Windows minidump writing API, so I have no idea how much memory it tries to allocate or anything like that. bug 587729 is the right long-term fix for this, I've been working up a prototype implementation recently, it's possible I could get it into the next release (or the one after that, depending on cycle time).
This is too old to track. So much has changed in how we stack walk (JSON for example).