853905 - Make Breakpad check for CFBundle version info for every dylib on OS X

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

Currently Breakpad crash reports on OS X don't contain proper version information for any loaded module aside from the "main executable" (i.e. Firefox or Thunderbird).  Instead it generates "debug ids" (hashes of some kind) for each of them.

If the module is the main executable of a CFBundle, its actual version number will be available in the bundle's Info.plist (present at a know location relative to the module).  This information is actually much more useful than the "debug id".  So if it's present Breakpad should record it instead of (or perhaps in addition to) the "debug id".

Bug 818664 records CFBundle version information for the "main" plugin in a child process.  But this is only for out-of-process plugins.  And the information is written to a "miscellaneous information" field that also has lots of other, potentially unrelated contents -- so it's difficult for Socorro to gather aggregate statistics on this information.

There's already a bug 520673, which appears to be about getting Breakpad to report dynamic library version information for each loaded module.  But this information is much less distinctive (and therefore interesting) than CFBundle information.  So you could argue that it's actually better to report a "debug id" than to report this information.

In any case, though, this bug is just about reporting the CFBundle version information, when present.

I'll see if I can cook up a patch that does what I want.

Comment 1

[(not currently active) Ted Mielczarek]

Just a few notes:
* Debug IDs are just the LC_UUID of the dylib if that exists
* Doing complicated things in Breakpad is hard because the code has to run in a potentially compromised process (could be heap corruption etc). If you just need to read a file and get some values out that's probably okay. If you need to run an XML parser on the plist, that's probably not ok.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

> * Debug IDs are just the LC_UUID of the dylib if that exists

That's makes sense.  But it also makes what I want to do a lot trickier.

I assumed Breakpad was generating hashes for each module.  And if it's safe to do this, it'd be safe to do quite a lot of other processing.

> If you need to run an XML parser on the plist, that's probably not ok.

Too bad, because that was exactly what I was planning to do, via Apple's CFDictionary apis.  I think I'm still going to try it.  I have some hope that Apple's underlying code is pretty efficient (since it's heavily used by Apple apps).

Does Breakpad have performance tests that I could use to find out how large a hit this change would make?  I'd use good performance as a proxy for "likely to be able to perform well in a compromised process".

Comment 3

[(not currently active) Ted Mielczarek]

We don't have performance tests for Breakpad. I would see if you can determine if the API is going to call malloc/new. If so, I would not use it. Alternately, if you could do this processing ahead-of-time (like gather the list of loaded modules when the ExceptionHandler is initialized, and observe module loads and handle them then instead of after an exception happens), that would probably be OK as well.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> Alternately, if you could do this processing ahead-of-time (like
> gather the list of loaded modules when the ExceptionHandler is
> initialized, and observe module loads and handle them then instead
> of after an exception happens), that would probably be OK as well.

This sounds more promising.  I'll try it.  (I already know from
experience that OS X has good apis for observing module loads.)

Thanks for the advice!

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Ted, here's a request for more advice:

I've started to learn how Breakpad works (which I currently know in only the most general way).  The first thing I do in such cases is to add printf() statements to parts of the code, to see if they get exercised (the output normally shows up in Terminal when I run the app from there, and in the system console).

I run my test build and then use your Crashme extension to crash it.  Breakpad shows up, but I don't see any printf() output.  Do you have any idea what's going on?

The two places I currently have printf() statements are MacFileUtilities::MachoID::IDCommand() and google_breakpad::DynamicImage::CalculateMemoryAndVersionInfo().

Comment 6

[(not currently active) Ted Mielczarek]

The DynamicImages code is only used for out-of-process reporting (like we use for plugin processes), IIRC. The MachoID code should be used.

You're seeing the Mozilla Crash Reporter? In that case the Breakpad code should have been triggered. The control flow should go through ExceptionHandler:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/client/mac/handler/exception_handler.cc#379

to MinidumpGenerator:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/client/mac/handler/minidump_generator.cc#203

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I got print() output from both of the places you suggested, but not (for some reason) MachoID::IDCommand().  So printf() logging from Breakpad does work.  I'll keep digging.

Thanks again!