mozilla/socorro — pull request #1145 by xni (2013-03-20 09:37:38+00:00)
Title: Processing broken dumps correctly

Hi!

We have faced with an exception on analysing some dumps.

Crashed application had a module without name, version, etc. (it is a separate question — why it exists).

Minidump -m output for this crash looks like that (see 2nd row):
```
...
Module|ATIRadeonX3000GLDriver|0.0.0.0|ATIRadeonX3000GLDriver|019C8FD32824C6F10FC3B2A339B4309D0|0x1c763000|0x1cb40fff|0
Module||||000000000000000000000000000000000|0x1f3b2000|0x1f3b2fff|1
Module|libgfl.dylib|0.1.0.0|libgfl.dylib|8DDB177A40A23D33A5FDE85BFB0599650|0x233b5000|0x234f9fff|0
...
```

If I execute minidump by hands, it produces output:
```
...
55 OurModuleName!OurFunction [our_code.cc : 32 + 0x15]
eip = 0x1f3b9af9 esp = 0xbffffb70 ebp = 0xbffffba8
Found by: previous frame's frame pointer
56 + 0xf77
eip = 0x1f3b2f78 esp = 0xbffffbb0 ebp = 0xbffffbb8
Found by: previous frame's frame pointer
57 + 0xf54
eip = 0x1f3b2f55 esp = 0xbffffbc0 ebp = 0xbffffbd0
Found by: previous frame's frame pointer
58 0x1
eip = 0x00000002 esp = 0xbffffbd8 ebp = 0x00000000
Found by: previous frame's frame pointer
```

As you can see, it is processed correctly, but does not have a module name.

minidump -m fails:
```
0|55|OurModuleName|OurFunction|our_code.cc|32|0x15
0|56|Aborted
$
```

I understand, that this is a problem of minidump, but it seems, that this solution is a universal guard against futher problems here.