Developers would like to be able to capture an application (sometimes involving layers) that provokes a driver crash. The capture would be very useful in determining exactly what went wrong in a debugging situation (particularly on Android, which is difficult to debug otherwise).

Right now, gfxreconstruct will only write to the trace file post-call; right now, this causes the offending command to be lost, as the driver will have crashed before the information would have been saved.

Here are a few brainstormed alternatives for supporting this use case:

A. Two-stage capture writing

The capture layer writes the call data to the capture file before the call is processed, with some indicator that the call has not yet been passed on. After the call returns, the capture layer goes back to the file using seek() or equivalent and writes the post-call information into the proper location in the capture file. (If the file format were arranged so that all the pre-call information came first, this could be done without using seek().)

gfxrecon-replay would have to behave correctly when used on a call that has only pre-call information written.

• ➕ standard gfxreconstruct tools still work correctly (e.g. gfxrecon-replay, gfxrecon-toascii, trimming)
• ➕ capture file (possibly trimmed) can potentially be used directly as a test case
• ➖ file architecture currently supports only streaming, with no random access

B. Trap exceptions during capture

The capture layer could trap exceptions and other crashes, and output in some format information about a the last call to be captured.

➖ difficult to detect and react to all crashes on all supported OSes
➖ crashing command does not go into the capture, so no way to collect this crash as a test case

C: As (B), but write the crashing command to the capture file after the crash

• ➕ standard gfxreconstruct tools still work
• ➕ capture file is complete and can be used as a test case
• ➕ supports streaming
• ➖ duplicates code somewhat