Sqlite 3.3.1 passed 'make test' on both of the below platforms that
3.2.8 did not.
I still had the 'date' issues under gentoo...the times missed by
1hr...likely something not quite right in the locale setup.
Russell Leighton wrote:
I get the following failures under 2 linux environments which might be
related to the below valgrind issue:
Failures on these tests: conflict-6.2 conflict-6.3 conflict-6.7
conflict-6.8 conflict-6.9 conflict-6.10 conflict-6.11 conflict-6.12
conflict-6.13
..when doing a 'make test' under:
FedoraCore4 , gcc4.1
Gentoo 2.6.14-gentoo-r5, gcc 3.3.5
On gentoo I also get these date failures (which I don't see under
FedoraCore4):
date-6.1 date-6.4 date-6.5 date-6.8 date-6.13 date-6.16
Russell Leighton wrote:
Recompiled using 3.2.8 of sqlite, same issue is flagged by valgrind.
Russell Leighton wrote:
Also, this happens under any constrained insert...from the stack
trace below you would that that would be true. This is confirmed
during another test scenario doing an insert statement into a
constrained tabled where I got the same warning about insert.c:980
Russell Leighton wrote:
During valgrind ( www.valgrind.org ) testing under linux I was
executing "vaccum" and got:
==17449== Conditional jump or move depends on uninitialised value(s)
==17449== at 0x1CF2200C: sqlite3GenerateConstraintChecks
(insert.c:980)
==17449== by 0x1CF233F6: sqlite3Insert (insert.c:629)
==17449== by 0x1CF2B72E: sqlite3Parser (parse.y:600)
==17449== by 0x1CF377BD: sqlite3RunParser (tokenize.c:388)
==17449== by 0x1CF2ED6B: sqlite3_prepare (prepare.c:440)
==17449== by 0x1CF3B376: execSql (vacuum.c:42)
==17449== by 0x1CF3B429: execExecSql (vacuum.c:61)
==17449== by 0x1CF3B721: sqlite3RunVacuum (vacuum.c:207)
==17449== by 0x1CF3D6AD: sqlite3VdbeExec (vdbe.c:4288)
==17449== by 0x1CF40F7B: sqlite3_step (vdbeapi.c:217)
Is this already known, or should I enter a bug?
Are pre-release regression tests done under valgrind or purify?
Might be a good idea.
Thx
Russ