mchbani / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

processor fails if an entry in the ModuleList is bad #222

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I have a minidump (submitted by a Mozilla user) that apparently has a bad
entry in the ModuleList.  The processor fails to process the ModuleList in
this case, and so the stack comes out without module names, which sucks.

The error from the processor is:
2007-10-17 21:22:23: minidump.cc:2094: ERROR: MinidumpModuleList could not
read module auxiliary data for module 36/62

The minidump file is attached, I'm going to take a look at it more in a
bit.  My immediate feeling is that this code:
     if (!module->ReadAuxiliaryData()) {
        BPLOG(ERROR) << "MinidumpModuleList could not read module auxiliary "
                        "data for module " <<
                        module_index << "/" << module_count;
        return false;
      }

should use |continue| instead of |return false|.  Not sure if we'd then
need to remove the offending module from the module list as well?

Original issue reported on code.google.com by ted.mielczarek on 18 Oct 2007 at 12:52

Attachments:

GoogleCodeExporter commented 9 years ago
Oh, duh, the error output was right before that error message:
2007-10-17 21:21:19: minidump.cc:1666: ERROR: MinidumpModule CodeView record 
size
7844 exceeds maximum 1024
2007-10-17 21:21:19: minidump.cc:1387: ERROR: MinidumpModule has no CodeView 
record,
but one was expected

The module in question is: C:\WINDOWS\system32\Syncor11.dll, which Google tells 
me is
some audio driver.  So it looks like it has bad or at least unexpected debug 
info,
and we barf on it.  Should definitely handle this more gracefully.

Original comment by ted.mielczarek on 18 Oct 2007 at 1:05

GoogleCodeExporter commented 9 years ago
From what I recall, syncor11.dll has debugging information right in the dll 
itself,
instead of carrying a link to a pdb.  We aren't equipped to do anything with 
that at
processing time, since it's not in dumped-symbol format.

Original comment by mmento...@gmail.com on 18 Oct 2007 at 4:26

GoogleCodeExporter commented 9 years ago
That's fine, I just think the processor should ignore it instead of dying on 
it. 
Could we just treat it as having no debug info?

Original comment by ted.mielczarek on 18 Oct 2007 at 5:06

GoogleCodeExporter commented 9 years ago
Sure!

Original comment by mmento...@gmail.com on 18 Oct 2007 at 7:55

GoogleCodeExporter commented 9 years ago
Ok, this makes it WFM.

Original comment by ted.mielczarek on 18 Oct 2007 at 8:34

Attachments:

GoogleCodeExporter commented 9 years ago
Checked in at revision 225.

Original comment by ted.mielczarek on 19 Oct 2007 at 6:45