collecting minidumps from test images

[Luigi Semenzato]

Hi, this may be of interest only internally to Google (but no big secrets).

We make extensive use of test images and we occasionally would like to analyze crashes whose minidump has been lost because of the 32 crash limit.

We can try to rig up a solution by adding a service that monitors the crash spool directory and selectively converts minidumps to text, and then dumps that text in the syslog or other logs (we use cloud logging so that part is taken care of).  But I am concerned that this may interact poorly with the crash reporter and I am wondering if there is a better way of integrating with it.

Any suggestions?  Thanks!

P.S. We can move this discussion internally if it becomes sensitive.

[Mike Frysinger]

i don't think we change behavior on test images because a very crashy program could fill up /var entirely which makes further logging/debugging difficult.

i also don't think we allow customization of the 32 limit.

if your scope is test images, i'm not seeing an issue here.  there are basically 2 moving parts:

* crash sender: responsible for uploading crashes to the server, but we don't do that on test images, so you can ignore it

* crash reporter: called when a crash happens from anywhere (e.g. coredump from the kernel) -- it only appends to the crash spool dir, it doesn't modify existing content

iirc crash reporter counts reports based on .meta files existing.  so if you wrote a service that periodically scans the spool dir for .meta files, and then does whatever processing you want before deleting it, you should be fine.

-mike

--
--
ChromiumOS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

[Luigi Semenzato]

Great, thanks!