backtrace-labs / crashpad

A fork of Crashpad with file attachment support and other improvements.
Apache License 2.0
101 stars 31 forks source link

Attaching files post-initialization #18

Open cjserio opened 2 years ago

cjserio commented 2 years ago

We've got a bit of an issue and I can only think of bad solutions so I'm hoping I've just overlooked something obvious. We're using the "attachments" argument to 'StartHandler' to attach our log file on a crash. This works great. The log file is always there on disk...it's always useful to us...and it's uploaded successfully every time.

The issue is that there are often needs to add MORE files at a later time....files that did not exist at the time the handler was started and whose name/location might not be predictable early either. These are non-fatal incidents where the process is still healthy. (A GPU error for example). We cannot find a way to add files later.

Some ideas that I considered: 1) Killing the existing handler and starting a NEW handler now that we have more specific file location information. There seems to be no exposed way to kill/restart a handler though. 2) Communicating with the handler to send more information via IPC. This would require customizing the handler source of course which isn't ideal. 3) Disable 'Uploads', write ourselves a private note somewhere to disk about the location/need of the extra files and then add them to the report the next time the app is restarted and THEN upload it. It seems like the only access to a 'Report' implies that its immutable and cannot easily add attachments to it. 4) Let the system upload reports without the extra attached files and then upload them directly to backtrace later. I've not found an API for this but maybe there's some URL we can use to send via CURL on a worker thread if we knew the report's UUID. 5) Add one or more placeholder paths to StartHandler. If we end up needing them later, we can rename the files to align with those paths. If we don't end up needing them, it seems like handler doesn't care that the files don't exist and will just log out an error but still continue just fine. This seems like it would work but it's a bit crude.

Would you guys have any recommendations on this issue?

Thanks!

cjserio commented 2 years ago

It seems like if we don't allow automatic uploads, we can simply put more files in the proper crash UUID's 'attachments' folder and they get uploaded auto-magically. This is a useful side-effect though the issue becomes knowing the UUID of the crash so we know where to move the attachment to the next time the app is run. I guess we can just got by the date/time stamps on the DMP and other files but I was hoping for a more reliable way.

I'd also love the ability to add more attributes post-crash. Users want to include notes about what they were doing at the time of the crash to help us as well as provide their information so we can contact them. I see no way of doing that without manually opening up the minidump and writing it directly. Perhaps we're just really petting the cat backwards with all of these intentions?

vlussenburg commented 2 years ago

Add one or more placeholder paths to StartHandler. If we end up needing them later, we can rename the files to align with those paths. If we don't end up needing them, it seems like handler doesn't care that the files don't exist and will just log out an error but still continue just fine. This seems like it would work but it's a bit crude.

Classically, this is what I've seen being used. It's even possible to create symlinks on the fly and have generic crashattachment_N attachment paths provided on startup. It's not very pretty, but it works.

Having said that, in the future, we could look at improving this.