On 6/2/2015 12:23 PM, Joerg Sonnenberger wrote:
On Tue, Jun 02, 2015 at 11:58:03AM -0700, Ross Berteig wrote:
This is the class of bug that the optimizer is likely to expose, and
that is difficult for tools to find. Valgrind would likely have found
it, but would have to have executed a test case that attempted to
generate the /reports page.

Actually, this is the class of bugs that Valgrind is very *bad* at
finding. msan should be able to find it, if the compiler is aggressive
enough about the life-time markers.

As a long time Windows user (and deeply embedded developer) I have often wished for Valgrind to be more available to me. On the rare occasions where I've been able to compile on some *nix platform too, I've been impressed by what it can find.

But now that I've had my lunch and coffee, you're right. Valgrind likely can't know because it doesn't seem to have an analysis tool that actively tracks variable lifetimes to a fine enough grain. Although a suitable set of compiler de-optimizations could in principle be used to adjust the valid bits for automatics as they go in and out of scope, I don't think that has been done. In practice it would still required a test suite that exercise "enough" code paths and "enough" individual lines of code to catch this kind of thing.

From a quick glance, MSan is trying to sneak up on the same problem from a different direction, and might be capable of poisoning values as they leave scope. I've never seen it before, and will make some time to learn more about it.

Regardless, this kind of data lifetime bug is why I have come to really enjoy dynamic languages (like Lua and TCL). Garbage collection brings its own set of issues, but this specific bug would not have happened in a language where the lifetime of values spans from being hung on a queue by one function and removed by another.

--
Ross Berteig                               r...@cheshireeng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/

_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to