I have solved the failed tests reported a few days ago, and I have now
the proof that none of them is blamed on sqlite.
For what it is worth, here are the details:
The source is sqlite 3.4.1 last updated on August 9
The platforms and compilers are:
- Enterprise 3, 32 and 64 bits, gcc 3.2.3
- Enterprise 4, 64 bits, gcc 3.4.4
- Fedora 5, 64 bits, gcc 4.1.1
The failures that recurred after several fulltest runs were:
- lock4-1.3 (error, the database is locked) on Enterprise 3, 32 bits
- malloc2-1.1.34 and malloc2.1.5, on Enterprise 3, 32 bits (checksums)
- printf-8.1 and printf-8.2 on Enterprise 3 and 4, 64 bits (error,
integer value too large to represent)
They were solved as follows:
1. lock4 seemed to be a delayed lock reset by the NFS service, affecting
only slow client machines.
When I ran fulltest it happened; meanwhile testfixture lock4.test, run
after a couple of minutes delay, would succeed the first time; if run
again immediately, it would fail again.
Solved by just moving everything to a local disk and repeating the tests.
2. malloc2.test would fail only if run immediately after malloc.test or
during fulltest. Probably another instance of something being delayed.
Stopped happening after the move to the local disk.
3. printf.test: The value too large to represent was 0x80000000 and the
message comes from tclObj.c:Tcl_Get_Int. Solved by getting tcl 8.4.15,
where the test that deals with differences between the int type and long
type on 64 bit boxes has been changed. On Fedora5 which has tcl8.4.13
this does not happen either.
The only useful lesson seems to be (a) use a new tcl and (b) stay away
from networks when testing or at least (c) test on a fast computer.
just my two bits,
yours truly,
Victor Secarin
Joe Wilson wrote:
The string "integer value too large to represent" is not found in
sqlite sources, so I assume it is an error in either in Tcl or the tcl
test harness.
I have no idea why the checksum of the databases in malloc2-1.1.28.5
is different, or whether it is harmless.
As for the malloc2.1.5 failure, as far as I can tell looking at the test,
an empty abc table should be present.
I have no idea about lock4-1.3.
I'd suggest to make a ticket for each of these test errors.
http://www.sqlite.org/cvstrac/tktnew
--- Victor Secarin <[EMAIL PROTECTED]> wrote:
Here are the fulltest errors I get trying to build sqlite 3.4.1 with the
included gcc on Enterprise 3, 4 and Fedora 5.
After building tcl8.4.7 and installing it in /usr/local, I was able to
configure with "--with-tcl=/usr/local/lib" and build the two libraries
completely and then run the fulltest on Enterprise 3 as well.
I hope someone will find these useful and will be able to tell me to
what extent the builds may be used or not.
Meanwhile, I will redo these builds, wit the Intel 9.1.052 compiler this
time, and I will post the fulltest results.
Please advise, and thank you very much,
Victor Secarin
A. Fulltest on Fedora 5 (64 bits) with glibc-2.4-11/gcc-4.1.1:
===========================================
3 errors out of 240587 tests
Failures on these tests: lock4-1.3 malloc2-1.1.28.5 malloc2.1.5
lock4-1.3...
Error: database is locked
malloc2-1.1.28.5...
Expected: [7150405b58e993f161c43b93edd13553]
Got: [bc598bca7e7514b7f36e3e3d178a97ba]
malloc2.1.5...
Error: no such table: abc
B. Fulltest on RedHat Enterprise 4 update 5 (64 bits) with
glibc-2.3.4-2.36/gcc-3.4.4:
============================================================
2 errors out of 127702 tests
Failures on these tests: printf-8.1 printf-8.2
printf-8.1...
Error: integer value too large to represent
printf-8.2...
Error: integer value too large to represent
====================================
C. Fulltest on Enterprise 3 update 9 (64 bits) with
glibc-2.3.2-95.50/gcc-3.2.3:
=======================================================
2 errors out of 127702 tests
Failures on these tests: printf-8.1 printf-8.2
printf-8.1...
Error: integer value too large to represent
printf-8.2...
Error: integer value too large to represent
D. Fulltest on Enterprise 3 update 9 (32 bits) with
glibc-2.3.2-95.50/gcc-3.2.3:
========================================================
3 errors out of 110199 tests
Failures on these tests: lock4-1.3 malloc2-1.1.34.5 malloc2.1.5
lock4-1.3...
Error: database is locked
malloc2-1.1.34.5...
Expected: [7150405b58e993f161c43b93edd13553]
Got: [bc598bca7e7514b7f36e3e3d178a97ba]
malloc2.1.5...
Error: no such table: abc
please advise, and thank you very much,
Victor Secarin
Joe Wilson wrote:
Can you post the output for the failed tests?
i.e.:
footest-13.1...
Expected: [10]
Got: [0]
--- Victor Secarin <[EMAIL PROTECTED]> wrote:
Hello, everyone. I just started to look at the software and I have two
questions:
Question 1:
========
Building sqlite-3.4.1, as obtained from the cvs, on Fedora 5, 64 bits,
with gcc 4.1.1, over glibc-2.4-11, and tcl/tcl-devel 8.4.13-1.1,
followed by "make fulltest", I get the following three failed tests:
lock4-1.3 malloc2-1.1.31.5 malloc2.1.5
Building the same with the Intel compiler icc 9.1.051, I get 8 failures
as follows:
bind-4.4 bind-4.5 expr-2.26 malloc2.1.5 printf-13.6 utf16-bind-4.4
utf16-bind-4.5 utf16-expr-2.26
____________________________________________________________________________________
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
