| HN Mirror

I'll try to come up with more ideas as they pop into my head, but given that you consume a binary, I'd like to see a service that consumes core dumps and does what " Automated Debugging for Arbitrarily Long Executions" (HotOS'13) does (a sort of reverse symbolic execution for find the root cause(s) of a the failure). An extension of this idea would be to operate on arbitrary program images, perhaps multiple images, as a mechanism of doing concolic execution.

Are you using concolic execution, or thinking of going in that direction as a way of generating more runtime-specific info, e.g. execution interleavings, data sharing, common values for memory locations, hot paths, etc.

I suppose a bunch of this is probably outlined in your API or integration with one's build system, but it would be great if a lot more about the process and capabilities of this system were detailed up front. For example, I think it would be useful to make some case studies of some programs, in a similar way that the Viva64 guy does for PVS-Studio, as a way of showing people how to use your system effectively.

Otherwise, I find the traces hard to digest. Unless there is some better interface for reading things, I think it would help convince people that your product is useful if, for example, your system reported the bugs it found in a very clear way. If debug info is in the binary then that should also be referenced, etc.

Finally, a passing note: I think your biggest "competitor" is going to be a tool like AddressSanitizer and other compiler extensions. I mean, I know solving more bugs is good for everyone and whatever gets the job done means better code out there, but I assume eventually you need to make money and convince people that you're going to solve a problem that a compiler extension can't. This is kind of the situation for DBT systems now :-P