578613 - Failed to process crash reports

Status: RESOLVED INVALID

(Socorro :: General, task)

Description

[Dave Townsend [:mossop]]

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

Comment 1

[(not currently active) Ted Mielczarek]

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?

Comment 2

[Dave Townsend [:mossop]]

(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)

Comment 3

[(not currently active) Ted Mielczarek]

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?

Comment 4

[Dave Townsend [:mossop]]

Yeah, 3.6.6

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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?

Comment 6

[Jens Müller (:tessarakt)]

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"

Comment 7

[Jonathan Watt [:jwatt]]

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

Comment 8

[(not currently active) Ted Mielczarek]

That generally means that the minidump was empty, which can occur for OOM crashes or heap corruption crashes.

Comment 9

[Jonathan Watt [:jwatt]]

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?

Comment 10

[(not currently active) Ted Mielczarek]

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).

Comment 11

[Peter Bengtsson [:peterbe]]

This is too old to track. So much has changed in how we stack walk (JSON for example).