On March 5, Richard Hipp wrote:
On Mon, Mar 5, 2012 at 1:39 PM, Larry Brasfield <larry_brasfield at iinet.com>wrote: > On March 5, Richard Hipp wrote: > > On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP <sreekumar.tp at gmail.com> >> wrote: >> >> > The crash is a result of -O3 flag used during compiling the library. >> > >> >> A compiler bug, then. OK. Good to know. SQLite has previously uncovered >> bugs in GCC, MSVC, and LLVM. Which compiler are you using? >> > > The fact that an optimization setting alters whether a C program crashes > or not does not imply that there is a compiler bug. Such a result might be > due to a code generation error. Or it might be due to code that is relying > upon undefined behavior, (such as evaluation order, content of struct gaps, > ad infinitum), and the exact (but undefined) behavior changes with > optimization setting. Additionally, pointer aliasing issues, while not > really in the realm of undefined behavior, can occur at higher optimization > levels. While a crash or other bad result that arises from pointer > aliasing might be counted as a compiler bug, it is generally better for > code to not create the opportunity. > Crashes at higher optimizations do not *prove* that the fault is in the compile, but in practice they are pretty good evidence of a compiler bug. The verified compiler bugs found by SQLite in GCC and MSVC occurred only at higher optimization levels. And we do run 100% branch test coverage on the SQLite code using multiple compilers, so one would hope that we have eliminated most cases of undefined behavior by this point.
I expect that your probabilistic assertion is perfectly valid for the SQLite codebase. In my own experience, working with code written by people who take less care than is evident in SQLite's code, code generation errors are less frequent than incorrect code that "benefits" from low optimization settings.
It is worth noting that the OP's problem may not implicate SQLite code at all. Anybody who does much debugging sees crashes that are due to delayed effects of a bug in code other than where a crash finally manifests the problem. In fact, I sought to qualify your "a compiler bug" assertion because if that leads the OP to ignore a real problem in his code, (now, or when similar situations arise), he will miss a good opportunity to correct something that may be hard to diagnose in other ways.
My comment was motivated by the idea that in debugging, we have to be careful about what we know versus what we suspect. I certainly agree that such bugs are unlikely in SQLite, for the reasons you mention among others relating to experience and methodology.
-- Larry Brasfield _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
