I recompiled my app using sqlite-3.3.1 and gcc4.1 and then ran w/valgrind.
Same issue (different line in insert.c):
=16584== Conditional jump or move depends on uninitialised value(s)
==16584== at 0x1CF23DA2: sqlite3GenerateConstraintChecks (insert.c:987)
==16584== by 0x1CF251AC: sqlite3Insert (insert.c:627)
==16584== by 0x1CF2D658: sqlite3Parser (parse.y:596)
==16584== by 0x1CF39C89: sqlite3RunParser (tokenize.c:392)
==16584== by 0x1CF30CF2: sqlite3_prepare (prepare.c:523)
==16584== by 0x1CF3DA26: execSql (vacuum.c:43)
==16584== by 0x1CF3DAD9: execExecSql (vacuum.c:62)
==16584== by 0x1CF3DE12: sqlite3RunVacuum (vacuum.c:213)
==16584== by 0x1CF3FB4B: sqlite3VdbeExec (vdbe.c:4483)
==16584== by 0x1CF438BB: sqlite3_step (vdbeapi.c:219)
==16584== by 0x1CE88CA7: aw_sqlite_execute_stmt (awsqlite.c:129)
...looking at insert.c:987 it is :
n1 = strlen(zErrMsg);
I did the same test on a gentoo system with gcc3.3.5 and no issue.
So, I am thinking this is a gcc4.1 bug.
[EMAIL PROTECTED] wrote:
Russell Leighton <[EMAIL PROTECTED]> wrote:
Thx.
I'll re-test with 3.3.1.
That said, isn't 3.2.8 supposed to be the stable release?
That depends on what you mean by "stable". If you mean
"unchanging", then yes, 3.2.8 is stable. The 3.2.x series
is closed and will never again change. All new code, all bug
fixes, etc, go into 3.3.x.
Please do not be mislead by the "alpha" label on 3.3.1.
Unless you are using the newer features, the CVS head
probably has far fewer bugs than 3.2.8.
--
D. Richard Hipp <[EMAIL PROTECTED]>
