Reporting custom crash reports using CrashPad.

[Pierre-Antoine Manzagol]

Hi crashpad-dev,

I'm interested in reporting a new type of stability data: structured data representing chromium's internal state. In the conventional case, this data is available in addition to the usual crash report data. In this case, the data can be added as an extra minidump stream. However, the data can also be available on its own. In this case, it can also be reported as a minidump, with the usual streams missing.

I'm currently focusing on the unconventional case. Based on previous exchanges, I've gone ahead and manufactured a minidump wrapper for the data (https://codereview.chromium.org/2128683002/).

My question are:

- How can I inform CP about the minidump that needs to be uploaded? (CP should handle assigning an id, consent validation, throttling).

- If the solution is an in process API, how could I register a callback to perform the harvesting and invoke the API?

Thanks,

Pierre 

[Mark Mentovai]

We don’t consider this an interface that we expose right now, so we should talk about that aspect of the problem, but really all you need to do is:

• Get a crashpad::CrashReportDatabase object. Depending on where you’re running, you may already have one. A Chrome browser process has one, it’s g_database in crashpad.cc. If you don’t have one yet, call crashpad::CrashReportDatabase::InitializeWithoutCreating(), giving it the path to the database on disk.
  
• Call PrepareNewCrashReport() on this object, which gives you a file handle you can write to.
• Call FinishedWritingCrashReport() when you’re done, or ErrorWritingCrashReport() to unwind. (CallErrorWritingCrashReport can help with the latter.)

If you do this from outside of the crashpad_handler process (which you will), the next crashpad_handler to start up will pick up your minidump. If a crashpad_handler is already running (as it normally would be), it should find your minidump within 15 minutes. It will upload it, or not, based on consent, rate-limiting, etc. I’d like to make this respond to filesystem notifications, but since all of our minidumps currently come from crashpad_handler which is able to signal the upload thread itself, this hasn’t been a priority.

One important note: in order for this all to work nicely, your minidump needs to encode the “crash keys” that the Breakpad-type server expects to see in the minidump itself, in a Crashpad-specific manner. See BreakpadHTTPFormParametersFromMinidump(). If you don’t do this, Crashpad won’t really care and it’ll still upload the minidump as you asked it to, but the Breakpad-type server will throw it away because it won’t be able to figure out what to do with it. Unfortunately for you, this is where Crashpad sticks the “prod”, “plat”, and “guid” parameters when it writes its own minidumps, and it’s where it retrieves them and sets them for the Breakpad-type server when it performs an upload. (Maybe we could make crashpad_handler fall back to using its process annotation values for these keys if it finds them unset in the minidump.)

But, like I said, none of this is considered an interface that we expose externally on our end.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To post to this group, send email to crashp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CA%2BAHSgYgW1uoCb-yJToZZ%3DbcXVt8kPczbNTAWdxPXBdgbEFLLQ%40mail.gmail.com.

[Scott Graham]

On Wed, Aug 3, 2016 at 2:39 PM, Pierre-Antoine Manzagol <manz...@chromium.org> wrote:

Hi crashpad-dev,

I'm interested in reporting a new type of stability data: structured data representing chromium's internal state. In the conventional case, this data is available in addition to the usual crash report data. In this case, the data can be added as an extra minidump stream. However, the data can also be available on its own. In this case, it can also be reported as a minidump, with the usual streams missing.

I'm currently focusing on the unconventional case. Based on previous exchanges, I've gone ahead and manufactured a minidump wrapper for the data (https://codereview.chromium.org/2128683002/).

My question are:

- How can I inform CP about the minidump that needs to be uploaded? (CP should handle assigning an id, consent validation, throttling).

For this one, I think you can use the existing CrashReportDatabase API which is already in client/ so is available. You can see an example of this here where the Crashpad handler writes its dumps:

https://cs.chromium.org/chromium/src/third_party/crashpad/crashpad/handler/win/crash_report_exception_handler.cc?rcl=0&l=80

Basically PrepareNewCrashReport(), write to the file handle it creates, and then FinishedWritingCrashReport(). It looks like we might want to add a way to tell the upload thread that a report is pending like we do after a crash (otherwise it won't try to upload your dump for up to 15m). Maybe Robert can comment on that idea.

This can but doesn't have to live in the handler process, see for example tools/crashpad_database_util.cc which also manipulates the database independent of the handler.

 

- If the solution is an in process API, how could I register a callback to perform the harvesting and invoke the API?

This one I'm less sure about. I guess we want a callback in that same function either right after the process is suspended, or right after Crashpad does its dump. But we don't have any existing in-process callbacks, so we'll have to figure out a way to plumb that through.

[Pierre-Antoine Manzagol]

Thanks for the quick and detailed replies Mark and Scott!

On Wed, Aug 3, 2016 at 6:10 PM, Mark Mentovai <ma...@chromium.org> wrote:

We don’t consider this an interface that we expose right now, so we should talk about that aspect of the problem, but really all you need to do is:

• Get a crashpad::CrashReportDatabase object. Depending on where you’re running, you may already have one. A Chrome browser process has one, it’s g_database in crashpad.cc. If you don’t have one yet, call crashpad::CrashReportDatabase::InitializeWithoutCreating(), giving it the path to the database on disk.
  
• Call PrepareNewCrashReport() on this object, which gives you a file handle you can write to.
• Call FinishedWritingCrashReport() when you’re done, or ErrorWritingCrashReport() to unwind. (CallErrorWritingCrashReport can help with the latter.)

If you do this from outside of the crashpad_handler process (which you will), the next crashpad_handler to start up will pick up your minidump. If a crashpad_handler is already running (as it normally would be), it should find your minidump within 15 minutes. It will upload it, or not, based on consent, rate-limiting, etc. I’d like to make this respond to filesystem notifications, but since all of our minidumps currently come from crashpad_handler which is able to signal the upload thread itself, this hasn’t been a priority.

One important note: in order for this all to work nicely, your minidump needs to encode the “crash keys” that the Breakpad-type server expects to see in the minidump itself, in a Crashpad-specific manner. See BreakpadHTTPFormParametersFromMinidump(). If you don’t do this, Crashpad won’t really care and it’ll still upload the minidump as you asked it to, but the Breakpad-type server will throw it away because it won’t be able to figure out what to do with it. Unfortunately for you, this is where Crashpad sticks the “prod”, “plat”, and “guid” parameters when it writes its own minidumps, and it’s where it retrieves them and sets them for the Breakpad-type server when it performs an upload. (Maybe we could make crashpad_handler fall back to using its process annotation values for these keys if it finds them unset in the minidump.)

Ah, I hadn't realized CrashPad would actually read the minidump.

I'll add the required information to the these to the structured data because the uploader might be of a different version than the data.