[sqlite] SQLite 2019-11-25 04:15:33 says 0 errors out of 250197 tests
I felt it was time to change the subject line to something more useful. Also everything works flawlessly here on Red Hat Enterprise Linux 7.4 : . . . SQLite 2019-11-25 04:15:33 b0b655625cf491c832a259d29a67660b8d5943c201617900a83d0660b2673377 0 errors out of 250197 tests on boe13.genunix.com Linux 64-bit little-endian All memory allocations freed - no leaks Maximum memory usage: 9267208 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls Excellent. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional Forwarded Message Subject: Re: [sqlite] What is the C language standard to which sqlite conforms ? Date: Mon, 25 Nov 2019 11:17:32 +0700 From: Dan Kennedy <.> Reply-To: SQLite mailing list To: sqlite-users@mailinglists.sqlite.org On 24/11/62 06:18, Dennis Clarke wrote: On 11/23/19 4:46 PM, Dan Kennedy wrote: Some follow up and thank you all for looking at this. Using this mornings trunk/current/head I do see the tests running well with these little exceptions : boe13$ pwd /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006 ... build clean as usual :-) tests run nicely now until ... Can you run: ./testfixture test/journal3.test and post the output? It would be my pleasure to get some light tossed on this ... so here is a very clean compile ( no -std in CFLAGS at all on gcc 9.2.0 ) and the tests look like so : This is a test script error. Should now be fixed here: https://sqlite.org/src/info/b0b655625cf491c8 . . . ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
It would be my pleasure to get some light tossed on this ... so here is a very clean compile ( no -std in CFLAGS at all on gcc 9.2.0 ) and the tests look like so : This is a test script error. Should now be fixed here: https://sqlite.org/src/info/b0b655625cf491c8 What version of Tcl are you using? 8.7a1 which tests clean here : Tests ended at Thu Nov 07 03:24:35 GMT 2019 all.tcl:Total 31405 Passed 30187 Skipped 1218Failed 0 Sourced 148 Test Files. Number of tests skipped for each constraint: 9 !ieeeFloatingPoint 3 asyncPipeChan 76 bigEndian 5 bug-3057639 49 dde 4 dontCopyLinks 63 emptyTest 5 fullutf 2 hasIsoLocale 1 knownBadTest 39 knownBug 100 localeRegexp 48 longIs32bit 14 macosxFileAttr 45 nonPortable 5 notNetworkFilesystem 1 obsolete 4 readonlyAttr 3 singleTestInterp 1 testexprparser && !ieeeFloatingPoint 7 testpreferstable 1 testwinclock 21 testwordend 189 thread 2 unthreaded 2 wideBiggerThanInt 504 win 4 winVista I'll take a look at https://sqlite.org/src/info/b0b655625cf491c8 and get a build going here shortly. Thank you very much Sir. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX called "munnari," for those who remember their history :-> I remember you however I started on BSD implementaions in 83 or 84 with the first real big workstations I had being the Apollo DN1000 and DN3000 boxen. Those things ran something called aegis which was essentially BSD. These were followed rapidly by the first big deskside Sun boxens on the old hypersparc or ross type chips in VME bus enclosures. Anyone recall the sweeping cpu led lights on the back of the cpu boards? Those were the early hardware implementations of the cylon ( BattleStar Gallactica and not the cool show either ) red eyes. Which was worth the price just to see them all going bonkers. Anyways .. yeah ... C and Fortran ( lots ) and Pascal but we don't talk about that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19 11:35 PM, Simon Slavin wrote: On 23 Nov 2019, at 11:06pm, Richard Hipp wrote: given the choice between (1) Code that works and does something useful (2) Code that is standards compliant I'll always go with (1). Another problem is that different compilers, or the same compiler with different options, warn about different things. And that making changes to make one compiler happy can make another compiler unhappy. Until you end up with complicated line here; /* actually does a = b but must keep four compilers happy */ Thanks !! I needed that. I have been pouring over this for two weeks and the real issue is test suite. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/23/19 4:46 PM, Dan Kennedy wrote: Some follow up and thank you all for looking at this. Using this mornings trunk/current/head I do see the tests running well with these little exceptions : boe13$ pwd /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006 ... build clean as usual :-) tests run nicely now until ... Can you run: ./testfixture test/journal3.test and post the output? It would be my pleasure to get some light tossed on this ... so here is a very clean compile ( no -std in CFLAGS at all on gcc 9.2.0 ) and the tests look like so : . . . Time: zipfile.test 442 ms Time: zipfile2.test 45 ms SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 250191 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Maximum memory usage: 9267192 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls gmake: *** [Makefile:1252: tcltest] Error 1 real 420.72 user 383.25 sys 23.47 boe13$ boe13$ ./testfixture test/journal3.test journal3-1.1... Ok journal3-1.2.1.1... ! journal3-1.2.1.1 expected: [0o644] ! journal3-1.2.1.1 got: [00644] journal3-1.2.1.2... Ok journal3-1.2.1.3... Ok journal3-1.2.1.4... ! journal3-1.2.1.4 expected: [0o644] ! journal3-1.2.1.4 got: [00644] journal3-1.2.1.5... Ok journal3-1.2.2.1... ! journal3-1.2.2.1 expected: [0o666] ! journal3-1.2.2.1 got: [00666] journal3-1.2.2.2... Ok journal3-1.2.2.3... Ok journal3-1.2.2.4... ! journal3-1.2.2.4 expected: [0o666] ! journal3-1.2.2.4 got: [00666] journal3-1.2.2.5... Ok journal3-1.2.3.1... ! journal3-1.2.3.1 expected: [0o600] ! journal3-1.2.3.1 got: [00600] journal3-1.2.3.2... Ok journal3-1.2.3.3... Ok journal3-1.2.3.4... ! journal3-1.2.3.4 expected: [0o600] ! journal3-1.2.3.4 got: [00600] journal3-1.2.3.5... Ok journal3-1.2.4.1... ! journal3-1.2.4.1 expected: [0o755] ! journal3-1.2.4.1 got: [00755] journal3-1.2.4.2... Ok journal3-1.2.4.3... Ok journal3-1.2.4.4... ! journal3-1.2.4.4 expected: [0o755] ! journal3-1.2.4.4 got: [00755] journal3-1.2.4.5... Ok SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 22 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Memory used: now 0 max 260520 max-size 12 Allocation count: now 0 max167 Page-cache used: now 0 max 0 max-size 1032 Page-cache overflow: now 0 max 2064 Maximum memory usage: 260520 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls boe13$ Let me know if there is anything else I can try here. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...
On 11/23/19 11:06 PM, Richard Hipp wrote: conforming to strict standards instead of what compilers actually do My problem here is that the compilers and their ability to comply with those wonderful cross platform standards is always a moving picture. Regardless it may be of some value to put a note somewhere on the sqlite webpages that says "just use GCC and don't specify -std" or something more helpful. Having said all that the use-after-free bug is real and we may yet have other problems in the test harness. I am still working through that and doing testing on a multitude of architectures ( risc / cisc / big endian / little endian and 32 and 64 bit ) which tends to reveal issues. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Regarding the whole C89/C90 language compliance debacle ...
very very stable and well : beta$ pwd /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005 beta$ beta$ echo $CFLAGS -m64 -xarch=sparc -Xc -g -mc -xs -errfmt=error -erroff=%none -errshort=full -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1 -xregs=no%appl -xdebugformat=dwarf beta$ echo $CC /opt/developerstudio12.6/bin/c99 beta$ I can report that the code compiles clean. However the testsuite is another matter : /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c: "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c", line 23: warning: empty translation unit (E_EMPTY_TRANSLATION_UNIT) /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c: "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c", line 2624: warning: argument #3 is incompatible with prototype: prototype: pointer to long : "/usr/local/include/tclDecls.h", line 2866 argument : pointer to long long (E_ARG_INCOMPATIBLE_WITH_ARG_L) sqlite3.c: "sqlite3.c", line 21610: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) "sqlite3.c", line 53745: warning: statement not reached (E_STATEMENT_NOT_REACHED) "sqlite3.c", line 87339: warning: statement not reached (E_STATEMENT_NOT_REACHED) "sqlite3.c", line 154637: warning: statement not reached (E_STATEMENT_NOT_REACHED) ld: warning: option -Q appears more than once, first setting taken Undefined first referenced symbol in file sched_yield test4.o ld: fatal: symbol referencing errors. No output written to testfixture gmake: *** [Makefile:1221: testfixture] Error 2 So on different systems with different architectures and compilers I get different behavior from very clean compliant code that I can not compile with gcc. This is all very confusing to me. Is my thinking wrong here in that I think that clean code should just compile everywhere with a good compiler? Note that I have not check on IBM Power not FreeBSD with LLVM/Clang but that is on my todo list. Ultimately I am trying to get to FreeBSD on a RISC-V platform here but that is a long way off. Next month I hope. In any case should I be seeing these failures ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/21/19 5:15 PM, Dan Kennedy wrote: On 22/11/62 00:06, Jens Alfke wrote: On Nov 21, 2019, at 7:01 AM, Richard Hipp wrote: The memset() just forces the bug to the surface in builds where the ckmalloc()/ckfree() routines of TCL are using caching that prevents valgrind/ASAN from seeing the use-after-free. The memset() is not part of the bug fixx itself, but is a preventative measure to try to prevent similar bugs in the future. This looks wrong to me: memset(p->pVfs, 0, sizeof(sqlite3_vfs)); memset(p, 0, sizeof(Testvfs)); ckfree((char *)p->pVfs); ckfree((char *)p); The second line zeroes the Testvfs struct pointed to by p; the third line reads the pVfs field of the struct, which is now NULL, and then calls free() on that NULL pointer, which is a no-op. The net result is to leak the heap block pointed to by p->pVfs. Shouldn't the second and third lines be swapped? They should indeed. Some follow up and thank you all for looking at this. Using this mornings trunk/current/head I do see the tests running well with these little exceptions : boe13$ pwd /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.006 ... build clean as usual :-) tests run nicely now until ... . . . . Time: zipfile2.test 44 ms SQLite 2019-11-21 20:24:04 ac080432b480062507452d3cdbe6c0f759e6f95b65d9862e0462017405ab2b8e 8 errors out of 250191 tests on boe13.genunix.com Linux 64-bit little-endian !Failures on these tests: journal3-1.2.1.1 journal3-1.2.1.4 journal3-1.2.2.1 journal3-1.2.2.4 journal3-1.2.3.1 journal3-1.2.3.4 journal3-1.2.4.1 journal3-1.2.4.4 All memory allocations freed - no leaks Maximum memory usage: 9267208 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls gmake: *** [Makefile:1252: tcltest] Error 1 real 410.99 user 376.39 sys 20.77 boe13$ Should we be concerned or are these artifacts from trunk/head/current? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/20/19 1:04 PM, Richard Hipp wrote: On 11/20/19, Dennis Clarke wrote: However the tests fail repeatedly with a code dump : Unable to reproduce the problem. What do you get when you run: ./testfixture test/walvfs.test What version of TCL are you linking against? For casual observers, please note that the segfault is in the test harness, not in SQLite itself. Probably it is an issue with the test harness itself and not a problem with the SQLite core. But we will see... boe13$ valgrind --version valgrind-3.15.0 boe13$ ldd testfixture linux-vdso.so.1 => (0x7ffcc0bf) libtcl8.7.so => /opt/bw/lib/libtcl8.7.so (0x7fb9c0949000) libdl.so.2 => /lib64/libdl.so.2 (0x7fb9c073b000) libz.so.1 => /opt/bw/lib/libz.so.1 (0x7fb9c051d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7fb9c0301000) libc.so.6 => /lib64/libc.so.6 (0x7fb9bff3d000) libm.so.6 => /lib64/libm.so.6 (0x7fb9bfc3b000) /lib64/ld-linux-x86-64.so.2 (0x556ca769) boe13$ boe13$ boe13$ valgrind --leak-check=full ./testfixture test/walvfs.test ==44169== Memcheck, a memory error detector ==44169== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==44169== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==44169== Command: ./testfixture test/walvfs.test ==44169== walvfs-1.0... Ok walvfs-1.1... Ok walvfs-1.2... Ok walvfs-1.3... Ok walvfs-2.0... Ok walvfs-2.1... Ok walvfs-2.2... Ok walvfs-2.3... Ok walvfs-3.0... Ok walvfs-3.1... Ok walvfs-3.2... Ok walvfs-4.0... Ok walvfs-4.1... Ok walvfs-4.2... Ok walvfs-5.0... Ok walvfs-5.1... Ok walvfs-5.2... Ok walvfs-5.3... Ok walvfs-5.3... Ok walvfs-5.4... Ok walvfs-5.5... Ok walvfs-5.6... Ok walvfs-6.0... Ok walvfs-6.1... Ok # WARNING: This next test takes around 12 seconds walvfs-6.2... Ok walvfs-7.0... Ok walvfs-7.1... Ok walvfs-8.0... Ok walvfs-8.1... Ok walvfs-8.2... Ok walvfs-8.3... Ok ==44169== Invalid read of size 8 ==44169==at 0x43C5D8: tvfsFileControl (test_vfs.c:527) ==44169==by 0x46C4E8: sqlite3OsFileControl (sqlite3.c:22475) ==44169==by 0x48A47D: databaseIsUnmoved (sqlite3.c:54928) ==44169==by 0x48A59B: sqlite3PagerClose (sqlite3.c:54969) ==44169==by 0x49BF11: sqlite3BtreeClose (sqlite3.c:66134) ==44169==by 0x54EBAB: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:157429) ==44169==by 0x54EACB: sqlite3Close (sqlite3.c:157372) ==44169==by 0x54EAEF: sqlite3_close (sqlite3.c:157385) ==44169==by 0x4611CE: DbDeleteCmd (tclsqlite.c:528) ==44169==by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184) ==44169==by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045) ==44169==by 0x464D44: DbObjCmd (tclsqlite.c:2219) ==44169== Address 0x7693ed8 is 88 bytes inside a block of size 240 free'd ==44169==at 0x4C2B27C: free (vg_replace_malloc.c:540) ==44169==by 0x4E763DC: TclpFree (tclAlloc.c:722) ==44169==by 0x4E8F8A4: Tcl_DbCkfree (tclCkalloc.c:651) ==44169==by 0x4E8FA89: Tcl_Free (tclCkalloc.c:769) ==44169==by 0x43E99F: testvfs_obj_del (test_vfs.c:1393) ==44169==by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184) ==44169==by 0x4E80178: Tcl_DeleteCommand (tclBasic.c:3045) ==44169==by 0x43E610: testvfs_obj_cmd (test_vfs.c:1296) ==44169==by 0x4E81E29: Dispatch (tclBasic.c:4418) ==44169==by 0x4E81EB6: TclNRRunCallbacks (tclBasic.c:4451) ==44169==by 0x4E81707: Tcl_EvalObjv (tclBasic.c:4181) ==44169==by 0x4E83BF5: TclEvalEx (tclBasic.c:5320) ==44169== Block was alloc'd at ==44169==at 0x4C29EC5: malloc (vg_replace_malloc.c:309) ==44169==by 0x4E763C2: TclpAlloc (tclAlloc.c:699) ==44169==by 0x4E8F0E0: Tcl_DbCkalloc (tclCkalloc.c:408) ==44169==by 0x4E8FA40: Tcl_Alloc (tclCkalloc.c:755) ==44169==by 0x43EDAD: testvfs_cmd (test_vfs.c:1550) ==44169==by 0x4E81E29: Dispatch (tclBasic.c:4418) ==44169==by 0x4E81EB6: TclNRRunCallbacks (tclBasic.c:4451) ==44169==by 0x4E81707: Tcl_EvalObjv (tclBasic.c:4181) ==44169==by 0x4E83BF5: TclEvalEx (tclBasic.c:5320) ==44169==by 0x4E82FC3: Tcl_EvalEx (tclBasic.c:4985) ==44169==by 0x4E85C67: Tcl_GlobalEval (tclBasic.c:6983) ==44169==by 0x468E37: main (tclsqlite.c:4008) ==44169== ==44169== Invalid read of size 8 ==44169==at 0x43C71B: tvfsFileControl (test_vfs.c:549) ==44169==by 0x46C4E8: sqlite3OsFileControl (sqlite3.c:22475) ==44169==by 0x48A47D: databaseIsUnmoved (sqlite3.c:54928) ==44169==by 0x48A59B: sqlite3PagerClose (sqlite3.c:54969) ==44169==by 0x49BF11: sqlite3BtreeClose (sqlite3.c:66134) ==44169==by 0x54EBAB: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:157429) ==44169==by 0x54EACB: sqlite3Close (sqlite3.c:157372) ==44169==by 0x54EAEF: sqlite3_close (sqlite3.c:157385) ==44169==by 0x4611CE: DbDeleteCmd (tclsqlite.c:528) ==44169==by 0x4E8032F: Tcl_DeleteCommandFromToken (tclBasic.c:3184) ==44169==by 0x4E80178: Tcl_DeleteCommand (tcl
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/20/19 3:45 PM, Richard Hipp wrote: On 11/20/19, Dennis Clarke wrote: In any case feels like a real problem. I am unable to reproduce the problem here. Can you run it under valgrind to see if that provides any other clues? I will give that a try. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/20/19 1:04 PM, Richard Hipp wrote:
On 11/20/19, Dennis Clarke wrote:
However the tests fail repeatedly with a code dump :
Unable to reproduce the problem. What do you get when you run:
./testfixture test/walvfs.test
What version of TCL are you linking against?
For casual observers, please note that the segfault is in the test
harness, not in SQLite itself. Probably it is an issue with the test
harness itself and not a problem with the SQLite core. But we will
see...
Oh yes this is the test suite situation which actually stops the install
process. Sure I could blindly install with the knowledge from extensive
hours and a few years looking over the sqlite code. Sure. However a test
report is sort of essential.
This is linked against tcl8.7a1 wherein I did see :
Tests ended at Thu Nov 07 03:24:35 GMT 2019
all.tcl:Total 31405 Passed 30187 Skipped 1218Failed 0
Sourced 148 Test Files.
Number of tests skipped for each constraint:
9 !ieeeFloatingPoint
3 asyncPipeChan
76 bigEndian
5 bug-3057639
49 dde
4 dontCopyLinks
63 emptyTest
5 fullutf
2 hasIsoLocale
1 knownBadTest
39 knownBug
100 localeRegexp
48 longIs32bit
14 macosxFileAttr
45 nonPortable
5 notNetworkFilesystem
1 obsolete
4 readonlyAttr
3 singleTestInterp
1 testexprparser && !ieeeFloatingPoint
7 testpreferstable
1 testwinclock
21 testwordend
189 thread
2 unthreaded
2 wideBiggerThanInt
504 win
4 winVista
So that is flawless. Also other software work has already proceeded
with that tcl.
Also :
boe13$ cd sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006
boe13$ ls -lapb ./testfixture
-rwxr-xr-x. 1 dclarke devl 5426184 Nov 20 04:35 ./testfixture
boe13$ ldd ./testfixture
linux-vdso.so.1 => (0x7fff993b6000)
libtcl8.7.so => /opt/bw/lib/libtcl8.7.so (0x7fd8119bd000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fd8117af000)
libz.so.1 => /opt/bw/lib/libz.so.1 (0x7fd811591000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fd811375000)
libc.so.6 => /lib64/libc.so.6 (0x7fd810fb1000)
libm.so.6 => /lib64/libm.so.6 (0x7fd810caf000)
/lib64/ld-linux-x86-64.so.2 (0x560607599000)
boe13$
boe13$ ./testfixture test/walvfs.test
walvfs-1.0... Ok
walvfs-1.1... Ok
walvfs-1.2... Ok
walvfs-1.3... Ok
walvfs-2.0... Ok
walvfs-2.1... Ok
walvfs-2.2... Ok
walvfs-2.3... Ok
walvfs-3.0... Ok
walvfs-3.1... Ok
walvfs-3.2... Ok
walvfs-4.0... Ok
walvfs-4.1... Ok
walvfs-4.2... Ok
walvfs-5.0... Ok
walvfs-5.1... Ok
walvfs-5.2... Ok
walvfs-5.3... Ok
walvfs-5.3... Ok
walvfs-5.4... Ok
walvfs-5.5... Ok
walvfs-5.6... Ok
walvfs-6.0... Ok
walvfs-6.1... Ok
# WARNING: This next test takes around 12 seconds
walvfs-6.2... Ok
walvfs-7.0... Ok
walvfs-7.1... Ok
walvfs-8.0... Ok
walvfs-8.1... Ok
walvfs-8.2... Ok
walvfs-8.3... Ok
Segmentation fault (core dumped)
boe13$
Let's try that in the debugger :
boe13$ TERM=dumb gdb -q ./testfixture
Reading symbols from
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.
(gdb) run test/walvfs.test
Starting program:
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/./testfixture
test/walvfs.test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
walvfs-1.0... Ok
walvfs-1.1... Ok
walvfs-1.2... Ok
walvfs-1.3... Ok
walvfs-2.0... Ok
walvfs-2.1... Ok
walvfs-2.2... Ok
walvfs-2.3... Ok
walvfs-3.0... Ok
walvfs-3.1... Ok
walvfs-3.2... Ok
walvfs-4.0... Ok
walvfs-4.1... Ok
walvfs-4.2... Ok
walvfs-5.0... Ok
walvfs-5.1... Ok
walvfs-5.2... Ok
walvfs-5.3... Ok
walvfs-5.3... Ok
walvfs-5.4... Ok
walvfs-5.5... Ok
walvfs-5.6... Ok
walvfs-6.0... Ok
walvfs-6.1... Ok
# WARNING: This next test takes around 12 seconds
walvfs-6.2... Ok
walvfs-7.0... Ok
walvfs-7.1... Ok
walvfs-8.0... Ok
walvfs-8.1... Ok
walvfs-8.2... Ok
walvfs-8.3... Ok
Program received signal SIGSEGV, Segmentation fault.
0x0043c71b in tvfsFileControl (pFile=0xa03c80, op=20,
pArg=0x7fffd918)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
549 if( p->pScript && (p->mask_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7.x86_64
(gdb) where
#0 0x0043c71b in tvfsFileControl (pFile=0xa03c80, op=20,
pArg=0x7fffd918)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1 0x0046c4e9 in sqlite3OsFileControl (id=0xa03c80, op=20,
pArg=0x7fffd918) at sqlite3.c:22475
#2 0x0048a47e in datab
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/20/19 12:12 PM, Richard Hipp wrote:
On 11/19/19, Dennis Clarke wrote:
CC=/opt/bw/gcc9/bin/gcc
CFLAGS=-std=iso9899:1999 -O0 -m64 -g -march=k8 -mtune=k8 \
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin \
-malign-double -mpc80
CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS \
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_GNU_SOURCE
I can get a compile and never a test.
Maybe try compiling without all the superfluous options? Does you
still get the failure then?
Perhaps tell us what the error is so that we can debug it?
That email is out of date and I submitted the current situation more
recently here.
Here is how things look :
CC=/opt/bw/gcc9/bin/gcc
CFLAGS=-O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double
CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_TS_ERRNO
CXX=/opt/bw/gcc9/bin/g++
CXXFLAGS=-std=c++11 -O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LDFLAGS=-L/opt/bw/lib -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
LD_RUN_PATH=/opt/bw/lib
PATH=/opt/bw/bin:/opt/bw/sbin:/opt/bw/gcc9/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/schily/bin
PERL=/opt/bw/bin/perl
Nothing else of any significance and the build goes just fine with :
boe13$ ./configure --prefix=/opt/bw --enable-shared --enable-static \
> --enable-readline --enable-threadsafe \
> --enable-tempstore=yes --enable-debug \
> --with-tcl=/opt/bw/lib
However the tests fail repeatedly with a code dump :
Time: walshared.test 26 ms
# WARNING: This next test takes around 12 seconds
gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
boe13$ gdb ./testfixture ./testdir/core.8032
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.
[New LWP 8032]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./testfixture
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00'.
Program terminated with signal 11, Segmentation fault.
#0 0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20,
pArg=0x7ffde61bc9f8)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
549 if( p->pScript && (p->mask_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7.x86_64 libgcc-4.8.5-16.el7.x86_64
(gdb) where
#0 0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20,
pArg=0x7ffde61bc9f8)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1 0x0046c4e9 in sqlite3OsFileControl (id=0x1509af0, op=20,
pArg=0x7ffde61bc9f8) at sqlite3.c:22475
#2 0x0048a47e in databaseIsUnmoved (pPager=0x1509970) at
sqlite3.c:54928
#3 0x0048a59c in sqlite3PagerClose (pPager=0x1509970,
db=0x14fbb70) at sqlite3.c:54969
#4 0x0049bf12 in sqlite3BtreeClose (p=0x159ea10) at sqlite3.c:66134
#5 0x0054ebac in sqlite3LeaveMutexAndCloseZombie (db=0x14fbb70)
at sqlite3.c:157429
#6 0x0054eacc in sqlite3Close (db=0x14fbb70, forceZombie=0) at
sqlite3.c:157372
#7 0x0054eaf0 in sqlite3_close (db=0x14fbb70) at sqlite3.c:157385
#8 0x004611cf in DbDeleteCmd (db=0x15bbab8)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:528
#9 0x7f9d19e18330 in Tcl_DeleteCommandFromToken (interp=0x1921c38,
cmd=0x1350f48)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3184
#10 0x7f9d19e18179 in Tcl_DeleteCommand (interp=0x1921c38,
cmdName=0x13acd98 "db")
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3045
#11 0x00464d45 in DbObjCmd (cd=0x15bbab8, interp=0x1921c38,
objc=2, objv=0x14ded88)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:2219
#12 0x7f9d19e19e2a in Dispatch (data=0x107d5e0, interp=0x1921c38,
result=0)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#13 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0x1921c38, result=0,
rootPtr=0x0)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#14 0x7f9d19e1c815 in TclEvalObjEx (interp=0x1921c38,
objPtr=0x61616161616
[sqlite] [Makefile:1256: tcltest] Segmentation fault (core dumped)
/nist/tcl8.7a1/generic/tclBasic.c:6018
#20 0x7f9d19e1c7ae in Tcl_EvalObjEx (interp=0xe832f8,
objPtr=0x6161616161616161, flags=0)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:5999
#21 0x7f9d19e40160 in Tcl_TimeObjCmd (dummy=0x0, interp=0xe832f8,
objc=2, objv=0xe87000)
at /opt/bw/build/nist/tcl8.7a1/generic/tclCmdMZ.c:4123
#22 0x7f9d19e19e2a in Dispatch (data=0x144c260, interp=0xe832f8,
result=0)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#23 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0xe832f8, result=0,
rootPtr=0x0)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#24 0x7f9d19e19708 in Tcl_EvalObjv (interp=0xe832f8, objc=5,
objv=0xe86880, flags=2097168)
---Type to continue, or q to quit---
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4181
#25 0x7f9d19e1bbf6 in TclEvalEx (interp=0xe832f8,
script=0x566360 "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
numBytes=430, flags=0, line=1, clNextOuter=0x0,
outerScript=0x566360 "if {[llength $argv]>=1}
{\nset argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource
$argv0\n} else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"}
{\nputs -nonewline \"> \"\n} else {\nputs -nonewl"...)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:5320
#26 0x7f9d19e1afc4 in Tcl_EvalEx (interp=0xe832f8,
script=0x566360 "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...,
numBytes=-1, flags=0) at
/opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4985
#27 0x7f9d19e1dc68 in Tcl_GlobalEval (interp=0xe832f8,
command=0x566360 "if {[llength $argv]>=1} {\nset
argv0 [lindex $argv 0]\nset argv [lrange $argv 1 end]\nsource $argv0\n}
else {\nset line {}\nwhile {![eof stdin]} {\nif {$line!=\"\"} {\nputs
-nonewline \"> \"\n} else {\nputs -nonewl"...)
at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6983
#28 0x00468e38 in main (argc=4, argv=0x7ffde61bd908)
at
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:4008
(gdb) quit
boe13$
so that is a nightmare given that the tcl build was flawless and clean
and passes all its tests.
Suggestions welcome.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/20/19 2:26 AM, Warren Young wrote: On Nov 19, 2019, at 7:06 PM, Dennis Clarke wrote: gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped) … CC=/opt/bw/gcc9/bin/gcc You’re using a nonstandard compiler (i.e. not provided by Red Hat) with non-default options, but it’s SQLite at fault here? Seems like quite a leap of logic to me. Where did you get that compiler binary? Or did you build it yourself? I think I know my way around building a production grade or release grade compiler. Thank you. You do your research first. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/19/19 8:43 PM, Keith Medcalf wrote: If using a GCC compiler, the dialect is -std=gnuXX where XX is the latest year supported by the compiler. In order these are: gnu89 gnu90, gnu9x, gnu99, gnu11, gnu1x, gnu17, gnu18, gnu19, gnu20, gnu2x This also happens to be the default if you do not specify -std The Source Code does NOT contain #ifdef's to "turn off" GNU extensions when a GNU compiler is being used, so if you are using a GNU compiler you MUST use it in a GNU compliant mode. The actual version that is required when using a GNU compiler is probably gnu89, that is, ANSI C with GNU extensions. I was waiting for the right person to respond. You are the right person. I generally, these days, wait until I see the names and voices that I have heard over the past ten or twenty years and then I really do pay attention. You Sir are the man today. :) So thank you. So you are saying that the code base is C89 clean but one should not or must not attempt to compile with a GCC compiler and specify a std such as -std=iso9899:1999 because the codebase makes no attempt to detect the GNU compiler? I am confused. Regardless my own experience and understanding is that the sqlite code is so clean that I could print it out onto the walls of a room and we have have a surgical theatre ready for heart transplant. However there is no such standard as "GNU compliant" and there seems to be things in the codebase that are just strange enough that I can not compile the code on a Red Hat Enterprise Linux machine with gcc 9.2.0. Having said all that you are saying "don't do that" and just let the code compile as is with a very few switches but certainly not -std=foo. With sqlite-src-3300100 I can not get very far due to the testsuite blowing up with a segfault : # WARNING: This next test takes around 12 seconds gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped) Now here I do want and need the ability to debug and thus my CFLAGS are: CC=/opt/bw/gcc9/bin/gcc CFLAGS=-std=iso9899:1999 -O0 -m64 -g -march=k8 -mtune=k8 \ -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin \ -malign-double -mpc80 CPPFLAGS=-I/opt/bw/include -D_POSIX_PTHREAD_SEMANTICS \ -D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_GNU_SOURCE I can get a compile and never a test. I think my real issue here is that I can get everything to compile neatly on some other system such as good ol' strict POSIX Solaris 10 with the Oracle Studio 12.6 tools and that is with insanely strict C99 compiler but can not get a good result on RHEL. Which is maddening. Even with a new shiney gcc. Would love to hear your thoughts. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] What is the C language standard to which sqlite conforms ?
On 11/19/19 12:32 AM, Scott Robison wrote: On Mon, Nov 18, 2019 at 3:44 PM Dennis Clarke wrote: Same question as a few days ago. This may have been asked many times before but always seems to be a valid question. On some machines with different compilers I get good results using C99 strict compliance. On other machines, such as those running Red Hat Enterprise Linux, I get terrible results. Per https://www.sqlite.org/howtocompile.html it is "ANSI-C". C89 is the ANSI-C standard, C90 is the first ISO-C standard. They are practically identical. Note that it is not strict ANSI-C, since ANSI-C doesn't provide for 64 bit integers, and it does not provide for platform specific APIs or functions. But as much as is possible, it is written to work with standard C as it has existed for about 30 years now. The code never passes its own test suite on Red Hat Enterprise Linux when compiled with strict C90 flags. In fact, the process segfaults. Actually it is worse than that. The strict C90 flags cause the gcc compiler to fail entirely due to the use of "asm" in the code. Yes I have tried gcc 9.2.0 and the whole process fails in the tests and no it will not compile as C90 code. Dennis Clarke ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] What is the C language standard to which sqlite conforms ?
Same question as a few days ago. This may have been asked many times before but always seems to be a valid question. On some machines with different compilers I get good results using C99 strict compliance. On other machines, such as those running Red Hat Enterprise Linux, I get terrible results. Also I am using a variety of LLVM/Clang and also GCC 8.x and 9.x as well as Oracle Studio 12.6 and also a few tests with less obvious compilers. This would be on 32-bit i386 and 32-bit armv7 and 64-bit ppc64 and Fujitsu sparcv9 and AMD Opteron and Intel x86_64 various types. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] What is the C language standard to which sqlite conforms ?
This may have been asked many times before but always seems to be a valid question. On some machines with different compilers I get good results using C99 strict compliance. On other machines, such as those running Red Hat Enterprise Linux, I get terrible results. Also I am using a variety of LLVM/Clang and also GCC 8.x and 9.x as well as Oracle Studio 12.6 and also a few tests with less obvious compilers. This would be on 32-bit i386 and 32-bit armv7 and 64-bit ppc64 and Fujitsu sparcv9 and AMD Opteron and Intel x86_64 various types. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] How to tell sqlite to only use tcl from the system?
I am seeing confusion here on a few systems wherein this : #include "sqliteInt.h" #if defined(INCLUDE_SQLITE_TCL_H) # include "sqlite_tcl.h" #else # include "tcl.h" #endif is in a pile of the test code. For some reasons I am seeing undefined symbols ( sched_yield ) and problems after getting past a build of 326 : . . . /usr/local/build/sqlite-src-326_Oracle_sparc64vii+.002/src/tclsqlite.c: sqlite3.c: "sqlite3.c", line 21319: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) "sqlite3.c", line 53307: warning: statement not reached (E_STATEMENT_NOT_REACHED) ld: warning: option -Q appears more than once, first setting taken Undefined first referenced symbol in file sched_yield test4.o ld: fatal: symbol referencing errors. No output written to testfixture gmake: *** [Makefile:1199: testfixture] Error 2 Current version does not build at all. Still locked in battle here on a few systems trying to get current release to build anywhere and thus far Solaris and RHEL both fail with references to tcl stuff in sqlite. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-src-3300100 on RHEL 7.4 toss mad errors about 'asm'
On 2019-11-07 11:44, Shawn Wagner wrote: ... Just don't use strict c99 mode when compiling with gcc? Drop the -std argument from your CFLAGS to use the default (gnu11 since gcc 5) or explicitly use gnu99, which gives you that version of the C standard + gcc extensions. (Not that they have anything to do with the problem, but compiling with -O0 and -fno-builtin are strange unless you're planning on spending some quality time in a debugger stepping through code, and -malign-double is already the default on x86-64 so kind of pointless) Debugger .. yes. That will happen and I build on a multitude of platforms. OKay so the code fails on Solaris sparc with c99 whereas in the recent past it all builds fine : libtool: compile: /opt/developerstudio12.6/bin/c99 -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -Xc -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -DSQLITE_OS_UNIX=1 -I. -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/rtree -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/icu -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/fts3 -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/async -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/session -I/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -I/usr/local/include -DSQLITE_THREADSAFE=1 -DSQLITE_HAVE_ZLIB=1 -DUSE_TCL_STUBS=1 -c /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c -KPIC -DPIC -o .libs/tclsqlite.o "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2346: error: undefined symbol: SQLITE_DBCONFIG_ENABLE_VIEW "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2346: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2351: error: undefined symbol: SQLITE_DBCONFIG_TRIGGER_EQP "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2351: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2352: error: undefined symbol: SQLITE_DBCONFIG_RESET_DATABASE "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2352: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2353: error: undefined symbol: SQLITE_DBCONFIG_DEFENSIVE "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2353: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2354: error: undefined symbol: SQLITE_DBCONFIG_WRITABLE_SCHEMA "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2354: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2355: error: undefined symbol: SQLITE_DBCONFIG_LEGACY_ALTER_TABLE "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2355: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2356: error: undefined symbol: SQLITE_DBCONFIG_DQS_DML "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2356: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2357: error: undefined symbol: SQLITE_DBCONFIG_DQS_DDL "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2357: error: non-constant initializer: op "NAME" "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c", line 2855: error: undefined symbol: SQLITE_DIRECTONLY c99: acomp failed for /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.001/src/tclsqlite.c gmake: *** [Makefile:1029: tclsqlite.lo] Error 1 On Red Hat Enterprise Linux 7.4 the code actually does compile and then core dumps with a segfault from with that same source file : Time: walshared.test 24 ms # WARNING: This next test takes around 12 seconds gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped) boe13$ pwd /opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.001 boe13$ find . | grep -i 'core' ./testdir/core.43494 boe13$ boe13$ file ./testdir/core.43494 ./testdir/core.43494: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './testfixture /opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00',
Re: [sqlite] sqlite-src-3300100 on RHEL 7.4 toss mad errors about 'asm'
On 2019-11-07 11:15, Shawn Wagner wrote: Does that toolchain use gcc, or a different compiler? If gcc, are you using the same CFLAGS as on the redhat box (you're turning on a bunch of extra non-default options there)? I don't see how --with-threads can be a concern. The other options do not qualify as a "bunch" at all. Regardless it looks like the codebase does strange GNU extensions. There must be a way to switch all that off. Dennis ps : don't top post. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-src-3300100 on RHEL 7.4 toss mad errors about 'asm'
On 2019-11-07 11:01, Shawn Wagner wrote: Compiling with -std=iso9899:1999 is the culprit. Strict c99 mode disables gcc extensions like inline asm. OKay but I have no issues doing a compile on a Solaris server using the Oracle Studio 12.6 tools and strict C99. So how is C99 the issue? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite-src-3300100 on RHEL 7.4 toss mad errors about 'asm'
^~ /opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.001/tool/mksourceid.c:620:5: note: in expansion of macro 'Rl0' 620 | Rl0(a,b,c,d,e, 0); Rl0(e,a,b,c,d, 1); Rl0(d,e,a,b,c, 2); Rl0(c,d,e,a,b, 3); . . . This all seems very strange as sqlite is usually a rock of gibraltar stable and easy process to get built and tested. What dumb thing did I do here ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite build on Risc-V
On 5/31/19 11:04 AM, Carlos Eduardo de Paula wrote: I tried to build SQLite from sources on Risc-V architecture but the ./configure script fails. Replacing config.guess and config.sub with the ones from automake 1.16 package fixes the problem and SQLite builds successfully. Carlos What system arch/type are you using? Is it rv64imafdc on a qemu type or a SiFive? Is it Linux or FreeBSD ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ISO8601 vs Numeric Timestamp for Date Storage
On 2/6/19 9:10 PM, Richard Hipp wrote: On 2/6/19, Ben Asher wrote: Hi there! We're having a debate at my company about date storage in SQLite. SQLite has builtin support for ISO8601 in its date functions, so some folks have started storing dates as ISO8601 SQLite-compatible date strings. Are In my own work, I have variously used ISO8601 text dates, unix timestamp integers, and fractional Julian Day numbers to represent dates and times, according to whichever worked best in that particular application. Since it is easy to convert between them all, this has never been a big problem. Why not merely use the data from : struct timespec tn; ec = clock_gettime( CLOCK_REALTIME, ); That should give some sort of data down to the nanosec and if you have decent ntp in place ( and black magic ) it may even be accurate. :-) -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] ISO8601 vs Numeric Timestamp for Date Storage
On 2/6/19 7:55 PM, Ben Asher wrote: Hi there! We're having a debate at my company about date storage in SQLite. SQLite has builtin support for ISO8601 in its date functions, so some folks have started storing dates as ISO8601 SQLite-compatible date strings. Are there pitfalls to storing dates this way compared to a unix timestamp? I'm curious to know if anyone has experience and would highly recommend sticking to one or the other for a particular reason. I'd also be grateful if anyone could point me to any articles exploring this subject. Thanks! Ben ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users Isn't ISO 8601 designed for communications with humans in an international and standard way? It is not for storage of data. At least in my opinion one needs a data element that one may store and later fetch and then perform computation and comparisons with. That would be the unix timestamp way of things. The ISO 8601 format is for display to human beings and other soft squishy creatures. I don't see how you can check two dates readily unless you have a pile of libs in your pocket that do that. So .. this works real well : l$ date -u ; tn; sleep 4; date -u; tn -f Wed Feb 6 20:40:54 UTC 2019 1549485654 Wed Feb 6 20:40:58 UTC 2019 1549485658.659547276 l$ Easy to compare those unix timestamps ripped out of an struct timespec. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-src-3260000 tests throw Error: couldn't fork child process: not enough memory
On 1/24/19 4:17 AM, Peter da Silva wrote: Sounds like something is using fork when it should be using vfork? No idea. My only concern is getting the sources to build clean and then to pass the testsuite. Which it doesn't due to one single itty bitty test. So how does one run a single test in isolation with full verbose debugging and annoying noisey level of chatter about what hurts? Time: sharedlock.test 42 ms ! shell1-1.7.1 expected: [0 1 1] ! shell1-1.7.1 got: [1 1 1] Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-src-3260000 tests throw Error: couldn't fork child process: not enough memory
On 1/23/19 7:10 PM, Richard Hipp wrote: On 1/23/19, Dennis Clarke wrote: Perhaps I was mistaken to enable --enable-tempstore=yes during configure ? Maybe. Does it work if you omit that option? The solution seems to be to throw hardware at the problem and then it goes away. I allocated 32G of memory to the process and also allowed the Solaris zone to lock 32G and everything runs with the exception of a single test : . . . Time: sharedA.test 1052 ms Time: sharedB.test 104 ms Time: sharedlock.test 42 ms ! shell1-1.7.1 expected: [0 1 1] ! shell1-1.7.1 got: [1 1 1] Time: shell1.test 7604 ms Time: shell2.test 841 ms Time: shell3.test 398 ms Time: shell4.test 319 ms Time: shell5.test 2315 ms . . . SQLite 2018-12-01 12:34:55 bf8c1b2b7a5960c282e543b9c293686dccff272512d08865f4600fb58238b4f9 1 errors out of 146673 tests on corv SunOS 64-bit big-endian !Failures on these tests: shell1-1.7.1 All memory allocations freed - no leaks Maximum memory usage: 9276472 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls gmake: *** [Makefile:1234: tcltest] Error 1 Not sure what the issue is with a tcltest Error or why some process called "testfixture" needed 2G of memory : PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 5 root0K0K sleep 99 -20 0:36:29 2.2% zpool-jupiter_r/166 29033 dclarke 2087M 221M sleep00 0:07:29 0.3% testfixture/2 27749 root 4976K 3760K cpu0 100- 0:00:15 0.1% prstat/1 119 root0K0K sleep 99 -20 7:19:26 0.1% zpool-jupiter_z/166 7 root0K0K sleep0 -20 0:03:13 0.0% vmtasks/8 2294 dclarke10M 8568K sleep00 0:00:00 0.0% testfixture/1 729 root 3096K 1600K sleep 590 0:02:44 0.0% dhcpagent/1 572 root 62M 23M sleep 590 0:02:22 0.0% poold/9 175 daemon 1896K 1264K sleep 60 -20 0:00:00 0.0% kcfd/3 235 root 2680K 1368K sleep 590 0:00:00 0.0% iscsi-initiator/2 327 root 2952K 2184K sleep 590 0:00:00 0.0% rpc.bootparamd/1 256 root 8056K 5256K sleep 590 0:00:24 0.0% ntpd/1 ZONEIDNPROC SWAP RSS MEMORY TIME CPU ZONE 0 53 156M 145M 0.2% 8:55:32 2.4% global 11 33 2150M 337M 0.5% 0:07:32 0.3% z_001 6 20 68M 92M 0.1% 0:00:29 0.0% z_005 5 16 41M 41M 0.1% 0:00:24 0.0% z_002 2 43 100M 122M 0.2% 0:01:53 0.0% z_000 4 20 70M 97M 0.1% 0:01:09 0.0% z_006 Also, since I am here with memory tossed at the issue : Time: between.test 70 ms Skipping bigmmap.test - requires SQLITE_MAX_MMAP_SIZE >= 8G Time: bigmmap.test 29 ms What do I do here? Set an env var SQLITE_MAX_MMAP_SIZE=17179869184 for 16G and then see what happens? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-src-3260000 tests throw Error: couldn't fork child process: not enough memory
On 1/23/19 7:10 PM, Richard Hipp wrote: On 1/23/19, Dennis Clarke wrote: Perhaps I was mistaken to enable --enable-tempstore=yes during configure ? Maybe. Does it work if you omit that option? I just tried without and also went back to sqlite-src-324 and they all fail in the same way. This has me baffled. I may try this with less strict CFLAGS but I don't see how that is related. I am checking my user session limits but there is nothing interesting there either. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite-src-3260000 tests throw Error: couldn't fork child process: not enough memory
On Oracle solaris 10 sparc with 16GB of memory I was surprised to see :
.
.
.
Time: keyword1.test 229 ms
Time: lastinsert.test 64 ms
Time: laststmtchanges.test 60 ms
(82 ms - want less than 1000) (80 ms - want less than 1000) Time:
like.test 188 ms
Time: like2.test 215 ms
Time: like3.test 56 ms
Time: limit.test 233 ms
Time: limit2.test 103 ms
Time: loadext2.test 38 ms
Time: lock.test 913 ms
lock2-1.1...
Error: couldn't fork child process: not enough memory
lock2-1.3...
Error: can't read "::tf1": no such variable
lock2-1.4...
Error: can't read "::tf1": no such variable
! lock2-1.5 expected: [1 {database is locked}]
! lock2-1.5 got: [0 {}]
lock2-1.6...
Error: can't read "::tf1": no such variable
lock2-1.7...
Error: can't read "::tf1": no such variable
! lock2-1.8 expected: [0 {}]
! lock2-1.8 got: [1 {cannot commit - no transaction is active}]
lock2-1.10...
Error: can't read "::tf1": no such variable
Time: lock2.test 39 ms
Time: lock3.test 35 ms
lock4-1.2...
Error: couldn't fork child process: not enough memory
lock4-1.3...
Error: invalid command name "db2"
lock4-999.1...
Error: can't delete "db2": command doesn't exist
Time: lock4.test 61 ms
Time: lock5.test 37 ms
.
.
.
Perhaps I was mistaken to enable --enable-tempstore=yes during configure ?
Any thoughts ?
Dennis
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? SQLite3 builds quite happily on the various SPARC S8 ... Can we stop talking about historical hardware? I have Apache httpd running neatly on new shiney Oracle M-class hardware. The point is Solaris 11.4 and Oracle Studio. Nothing else. Dennis Clarke ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/20/19 12:50 AM, Gary R. Schmidt wrote: On 20/01/2019 15:03, Dennis Clarke wrote: On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Really? We are talking about Solaris 11.4 and not ye old Solaris 10 or other historical artifacts. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/19/19 10:55 AM, Igor Korot wrote: Dennis, On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke wrote: And SPARC version is still available for download... Let us know when you get that running. Install of x86 went very smooth. The x86_64 process is trivial. And I was able to compile fairly recent SQLite with Oracle Studio 12.6 with just couple of warnings... Which problem did you experience on SPARC? It is a nearly impossible process. Can not be done unless you have a very specific class of hardware. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
And SPARC version is still available for download... Let us know when you get that running. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 1/19/19 4:47 PM, Andy Goth wrote: Dennis Clarke wrote: On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) It may be [worth] while to spin up a Solaris 9 zone on a Solaris 10 or Solaris 11 server for this purpose. I don't have access to any Solaris servers of any kind. And yet, I had the requirement to produce a working binary for a computer I wasn't even allowed to go visit. It was rough, but the task is done and sold off. From the better late than never file eh? I have no idea how you managed to land that task but these days if someone asks me to do any work on a Solaris 8 or 9 server I simply say "no" and that is the end of it. I have seen too many nights and days lost to cursing over old Solaris 8 sparc servers. I have a few Solaris 10 servers left in life and zero, none, nothing for Solaris 11 simply because Oracle made it impossible to run. So well done and now do your self a favour and say good bye to it. Time to go look at Debian and FreeBSD on RISC-V if you want adventure! Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question about floating point
On 12/19/18 7:51 PM, James K. Lowden wrote: On Tue, 18 Dec 2018 17:34:29 -0500 Dennis Clarke wrote: some serious reading and experiments are needed to get a good handle on why numerical computation is as much art as it is science. If we wander into the problem without sufficient study and VERY careful consideration then we are doomed to repeat the errors of the past. I think perhaps you left out "Numerical Methods for Scientists and Engineers", by Richard Hamming. :-) I figure that if you are in the industry and have any experience at all then you know that old gem by heart. A more interesting topic of discussion would be the speed and complexity of circuitry designed for another number base such as 5 or even decimal. All of our collective experience over the past fifty years has been marching towards ever more effective digital logic for our de facto standard binary using the usual circuit assumptions and Moore's law has been profitable to so many corporations. Anyone can manufacture a 15nm product with $15M thus here we are in 2018 looking at verilog designs and 9nm multi-layer manufacturing for the next decade. We are caught collectively in the economics and thinking of binary. So we should look away from that for a moment. I do NOT mean the usual undergrad 4 bit adder logic which we all know entirely too well. Let's go lower down into the switch design that shall render sensor logic with at least ten voltage levels and perhaps, in my own ideas, twelve for guard logic at either end of the range. The real issue on the table initially would be transducer slew rates and noise control. Anyway, this is all off topic at this point. Dennis Clarke ps: feel free to see https://www.youtube.com/watch?v=AOC7KmHvx9w ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question about floating point
Apologies ... I should have included a link to Jean-Michel Muller's work on "Elementary Functions" and on preserving monotonicity and always getting correctly rounded results when implementing the elementary functions in floating-point arithmetic. https://link.springer.com/book/10.1007/978-1-4899-7983-4 Also an interesting read in IEEE Transactions on Computers, Vol 66, Issue 12 : Exponential Sums and Correctly-Rounded Functions. https://ieeexplore.ieee.org/document/7891945 ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question about floating point
On 12/18/18 6:01 AM, R Smith wrote:> On 2018/12/17 11:53 PM, Dennis
Clarke wrote:
>>
>> This thread is getting out of hand. Firstly there is no such binary
>> representation ( in this universe ) for a trivial decimal number such as
>> one tenth ( 0.10 ) and really folks should refer to the text book
>> recently published ( 2nd Edition actually ) where all this is covered
>> : //
>
>
> My good man, did the discussion really irritate you ...
[WARNING : written with a smile ]
Well, I guess the real issue is that I see fairly baseline stuff going
in circles over and over and over and over and very little clarity. I
merely posted that textbook because it really was written by the experts
and I have done a fair amount of emails in life back and forth to a few
of the authors on various topics who always cleared the air. They really
are the experts and the only name missing from that list is the great
and dreaded William Kahan himself. I say that with a smile as Professor
Emeritus of Mathematics Kahan is well known to write very bluntly about
people who have not a clue about trivial things. Trivial to him. The
rest of us merely try to catch up and get a solid understanding of the
basics which, as I was saying, have been covered over and over and over
and over in circles over and over and it gets ... annoying to walk into
a store and hear Beethoven's Ninth Symphony played over dirty cheap
speakers. Certainly when I have heard live performances a few times in
my life. Very irritating is the word.
I see this sort of thing happen from time to time and I have to take the
approach of 'care' or 'do not care'. In the case of the store with bad
speakers the option is 'do not care' and simply accept the noise. In the
case were good people can be led down a wrong path and then fall into a
pitfall or trap I feel 'care' happens. I am not a sociopath nor some
old greybeard UNIX geek that merely enjoys retirement too much to 'care'
anymore.
So let's play a little game based on an early lesson from William Kahan
which will demonstrate how poorly floating point works when used with
nothing but blind trust in bit games. Also we will assume that we are
going to play by the rules of his IEEE 754 and I may make a passing
reference to these three documents :
1 ) IEEE 754-2008 - IEEE Standard for Floating-Point Arithmetic
https://standards.ieee.org/standard/754-2008.html
2 ) Formal Verification of Floating-Point Hardware Design
https://www.springer.com/us/book/9783319955124
3 ) Handbook of Floating-Point Arithmetic
https://www.springer.com/us/book/9783319765259
4 ) The Art of Computer Programming
https://cs.stanford.edu/~knuth/taocp.html
5 ) Oral history interview with Donald E. Knuth
Charles Babbage Institute, 2001
https://conservancy.umn.edu/handle/11299/107413
6 ) How Futile are Mindless Assessments of Roundoff
in Floating-Point Computation ?
Prof William Kahan
https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf
Also perhaps ISO/IEC/IEEE 60559:2011 and working group ISO/IEC
JTC1/SC22/WG11 publications.
Let's begin with a quick and incomplete definition of "floating point"
data representation thus :
Given a radix B with precision p we express a 'floting point'
number in the format
[ (+/-)m_0 . m_1 m_2 m_3 ... m_(p-1) ] * B^e
where we call e the exponent which is always an integer and the
expression m_0 . m_1 m_2 m_3 ... m_(p-1) will be called the not
so friendy word "significand" which is expressed in radix B.
A complete and formal definition will be found in chapter 3 of reference
(3) above. This is not a new idea and in fact is quite old. One may find
a fairly nice history of "floating point" in computing machines such as
the Babbage difference engine ( see Charles Babbage et. al. ) and other
machines that performed numerical computation in (4) and (5) above.
Suffice it to say that radix 60 mathematics was common in the Babylonian
history and the Yale Babylonian Collection provides a tablet with an
approximation of the positive square root of two with four sexagesimal
digits 1, 24, 51, 10. Numerical data representation is not new at all
however I personally fell into the problem in while working on long term
trajectory computations with early Apollo systems. We had not yet been
able to establish a formal method to detect and handle numerical error
conditions and the much loved William Kahan provides us this rather
trivial example to illustrate:
Given u_0 = 2 and u_1 = -4 we then compute
u_[n] = 111 - 1130/(u[n-1]) + 3000/(u[n-1]*u[n-2])
where n > 1 clearly.
Trivial :
#include
#include
#include
#define LOOPCNT 30
int main (int argc, char *argv[])
{
long double u[LOOPCNT];
int j;
u[0] = (long double)2.
Re: [sqlite] Question about floating point
On 12/17/18 3:19 PM, Darren Duncan wrote: On 2018-12-17 9:16 AM, James K. Lowden wrote: On Sat, 15 Dec 2018 01:24:18 -0800 Darren Duncan wrote: If yours is a financial application then you should be using exact numeric types only Color me skeptical. That very much depends on the application. IEEE double-precision floating point is accurate to within 15 decimal digits. The example given, This thread is getting out of hand. Firstly there is no such binary representation ( in this universe ) for a trivial decimal number such as one tenth ( 0.10 ) and really folks should refer to the text book recently published ( 2nd Edition actually ) where all this is covered : Handbook of Floating-Point Arithmetic Authors: Muller, J.-M., Brunie, N., de Dinechin, F., Jeannerod, C.-P., Joldes, M., Lefèvre, V., Melquiond, G., Revol, N., Torres, S. This handbook is a definitive guide to the effective use of modern floating-point arithmetic, which has considerably evolved, from the frequently inconsistent floating-point number systems of early computing to the recent IEEE 754-2008 standard. I reviewed this chapter by chapter and have looked over the code and if people were to study the actual mathematics then this whole discussion would be moot. Okay ... so enough is enough here. Dennis Clarke ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] minor nit pick of "When To Use"
On 11/11/18 8:38 AM, Dennis Clarke wrote: On 11/11/18 8:25 AM, J. King wrote: On November 11, 2018 8:04:51 AM EST, Dennis Clarke wrote: this : https://www.sqlite.org/whentouse.html he.net is Hurricane Electric, an Internet backbone. An IX ? https://www.peeringdb.com/asn/6939 in a big way ... cool. dc ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] minor nit pick of "When To Use"
On 11/11/18 8:25 AM, J. King wrote: On November 11, 2018 8:04:51 AM EST, Dennis Clarke wrote: this : https://www.sqlite.org/whentouse.html he.net is Hurricane Electric, an Internet backbone. An IX ? Ah yes .. those guys ... been around forever. I should just "know that" but forgot. Regardless the whole reference to "fopen()" is a bit of a joke. dc ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] minor nit pick of "When To Use"
this : https://www.sqlite.org/whentouse.html I know this is really a nit pick but I see that the OpenGroup folks have published a new shiney UNIX standard called SUSv4 or Single UNIX Specification version 4 or even ye "The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)" just for fun. This : http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm Where we see the "standard" fopen is : http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html Not exactly a manpage to be sure but it is the standard. So perhaps a link could be placed on the top of the "When To Use" beside the "fopen()" manpage thing to "he.net" whatever that is. Surely the "competes with fopen()" is a small joke in any case. OKay I will go back to picking nits. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Segmentation Fault When Using Window Function
On 11/08/2018 04:05 PM, Richard Hipp wrote: In case you are not following the ticket at... The list mail server sends this out about thirty times. Not sure if anyone else sees abusive duplicates from the sqlite mail list server but I certainly do. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: float granularity breaking unique contraint?
INSERT INTO TestReal values (9223372036854775807);INSERT INTO TestReal values (9223372036854775807 - 1);INSERT INTO TestReal values (9223372036854775807 - 2);INSERT INTO TestReal values (9223372036854775807 - 3);sqlite>...>...>...>...> I recognize that number on sight and it would be more clear to everyone if it were expressed in hex 0x7fff. At the limit of int64_t. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Safe sqlite over remote filesystem?
Read all of this repeatedly. Excellent post. But if your nfs solution is configured not to lie, to honour lock and sync Had to pop up here briefly. I ran into a number of problems with nfs clients of various types wherein the most brutal would be VMware ESXi hosts. Running backend network attached storage from Oracle which is actually based on Solaris with ZFS can be terrifying if the actual disk controllers are doing cache at all. ZFS is a filesystem that uses tons of memory for cache and actual flush of writes to on disk happens long after a given IO operation has long since been complete. Migration away from NFS to iSCSI was a smart choice and I wonder if you have any iSCSI attached devices and what have you seen ? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure
On 07/30/2018 03:59 AM, Gary R. Schmidt wrote: On 2018-07-28 08:33, Andy Goth wrote: SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) It may be work while to spin up a Solaris 9 zone on a Solaris 10 or Solaris 11 server for this purpose. Not sure how you are getting a cross compile to work at all with just /usr/include on hand. Are you using the Sun Studio compilers for this ? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] building sqlite-src-3240000 I was surprised to see "make test" fail
libsqlite3.so.0.8.6 -rw-r--r-- 1 dclarke devl 212160 Jun 21 20:07 libtclsqlite3.a lrwxrwxrwx 1 dclarke devl 19 Jun 21 20:07 libtclsqlite3.la -> ../libtclsqlite3.la -rw-r--r-- 1 dclarke devl1029 Jun 21 20:07 libtclsqlite3.lai -rwxr-xr-x 1 dclarke devl 217824 Jun 21 20:07 libtclsqlite3.so -rw-r--r-- 1 dclarke devl 3028256 Jun 21 20:06 sqlite3.o -rw-r--r-- 1 dclarke devl 211640 Jun 21 20:07 tclsqlite.o So then a quick edit of the Makefile to add "-lrt" in there : n0$ diff Makefile.backup Makefile 70c70 < TLIBS = -lz $(LIBS) --- > TLIBS = -lz -lrt $(LIBS) n0$ ta da ! beautiful results : . . . SQLite 2018-06-04 19:24:41 c7ee0833225bfd8c5ec2f9bf62b97c4e04d03bd9566366d5221ac8fb199a87ca 0 errors out of 144287 tests on node000 SunOS 64-bit big-endian All memory allocations freed - no leaks Maximum memory usage: 9275952 bytes Current memory usage: 0 bytes Number of malloc() : -1 calls So now I will reproduce this across a few other systems and just be happy. Dennis Clarke [1] actually rolled into production on various risc platforms and multiple flavors of linux and unix types. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] building sqlite-src-3240000 I was surprised to see "make test" fail
On 06/21/2018 12:06 PM, Richard Hipp wrote: On 6/21/18, Dennis Clarke wrote: Seems to compile fine and yet "gmake test" failed with a less then helpful "Error 2" : . . . sqlite3.c: "sqlite3.c", line 20826: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) According to my manpage for localtime_r(), the only header file required is , which you can clearly see is found on line 20342, above the declaration that offends your compiler. Perhaps you can suggest what is going wrong, because I have no clue. Yep ... I looked there right away. Saw the same thing and then started over from scratch with more lenient CFLAGS. Build completes just fine ... near as I can tell. "sqlite3.c", line 52491: warning: statement not reached (E_STATEMENT_NOT_REACHED) Line 52491 is "assert(0);" which generates no code unless you compile with -DSQLITE_DEBUG. Once again, I have no explanation for the warning. Hr ... yep. Does make me wonder. I went out on a limb and figured that the tests were beig built and linked by default against the previous sqlite libs installed in the /usr/local/lib directory. So I went ahead and installed the libs freshly built and went back to run the "gmake test" and that was, at the very least, interesting : n0$ /usr/local/bin/gmake test 2>&1 | tee ../sqlite-src-324_SunOS5.10_sparcv9.002.test.log ./fuzzcheck --limit-mem 100M /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata1.db /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata2.db /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata3.db /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata4.db /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata5.db /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/fuzzdata6.db fuzzdata1.db: SQL fuzz as of 2015-06-20 fuzzdata1.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 9903 tests fuzzdata2.db: SQL test cases contributed by Michal Zalewski on 2015-05-01 fuzzdata2.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 9959 tests fuzzdata3.db: Database fuzz as of 2015-06-24 fuzzdata3.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 2316 tests fuzzdata4.db: JSON1 test cases as of 2015-09-23 fuzzdata4.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 2574 tests fuzzdata5.db: Test cases received from the OSS-FUZZ project fuzzdata5.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 8818 tests fuzzdata6.db: Test cases for UPSERT fuzzdata6.db: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% - 3896 tests fuzzcheck: 0 errors out of 37466 tests in 70.355 seconds SQLite 3.24.0 2018-06-04 19:24:41 c7ee0833225bfd8c5ec2f9bf62b97c4e04d03bd9566366d5221ac8fb199a87ca ./sessionfuzz run /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/test/sessionfuzz-data1.db sessionfuzz-data1.db: 339 cases, 0 crashes ./srcck1 sqlite3.c ./libtool --mode=link /opt/developerstudio12.6/bin/cc -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -m64 -xarch=sparc -errwarn=%none -erroff=%none -errtags=yes -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DSQLITE_OS_UNIX=1 -I. -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/src -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/ext/rtree -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/ext/icu -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/ext/fts3 -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/ext/async -I/usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/ext/session -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -I/usr/local/include -DSQLITE_THREADSAFE=1 -DSQLITE_HAVE_ZLIB=1 -L/usr/local/lib -DSQLITE_NO_SYNC=1 -DSQLITE_TEMP_STORE=1 -DSQLITE_TEST=1 -DSQLITE_CRASH_TEST=1 -DTCLSH_INIT_PROC=sqlite3TestInit -DSQLITE_SERVER=1 -DSQLITE_PRIVATE="" -DSQLITE_CORE -DBUILD_sqlite -DSQLITE_SERIES_CONSTRAINT_VERIFY=1 -DSQLITE_DEFAULT_PAGE_SIZE=1024 -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_DBPAGE_VTAB \ . . . etc etc . . . and then whammo : /usr/local/build/sqlite-src-324_SunOS5.10_sparcv9.002/src/tclsqlite.c: sqlite3.c: "sqlite3.c", line 52491: warning: statement not reached (E_STATEMENT_NOT_REACHED) Undefined first referenced symbol in file sched_yield test4.o ld: fatal: symbol referencing errors. No output written to testfixture gmake: *** [Makefile:1161: testfixture] Error 2 n0$ Interesting. n0$ grep -in "sched_yield" ./src/test4.c 80: while( p->opnum<=p->completed ) sched_yield(); 88:while( p->opnum<=p->compl
Re: [sqlite] building sqlite-src-3240000 I was surprised to see "make test" fail
On 06/21/2018 10:04 AM, Dan Kennedy wrote: On 06/21/2018 02:34 PM, Dennis Clarke wrote: Seems to compile fine and yet "gmake test" failed with a less then helpful "Error 2" : . . . sqlite3.c: "sqlite3.c", line 20826: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) "sqlite3.c", line 52491: warning: statement not reached (E_STATEMENT_NOT_REACHED) gmake: *** [Makefile:1161: testfixture] Error 2 Seems like the compiler is configured to be extra picky. Is this Solaris? Can you post the full output of [configure && gmake test]? It is and yes it is a very strict compiler. Which is why I use it. output from configure : checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... /opt/developerstudio12.6/bin/cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /opt/developerstudio12.6/bin/cc accepts -g... yes checking for /opt/developerstudio12.6/bin/cc option to accept ISO C89... none needed checking for a sed that does not truncate output... /usr/local/bin/sed checking for grep that handles long lines and -e... /usr/local/bin/grep checking for egrep... /usr/local/bin/grep -E checking for fgrep... /usr/local/bin/grep -F checking for non-GNU ld... /usr/ccs/bin/sparcv9/ld checking if the linker (/usr/ccs/bin/sparcv9/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/xpg4/bin/nm -p checking the name lister (/usr/xpg4/bin/nm -p) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 786240 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/ccs/bin/sparcv9/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for ar... /usr/ccs/bin/ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/xpg4/bin/nm -p output from /opt/developerstudio12.6/bin/cc object... ok checking how to run the C preprocessor... /opt/developerstudio12.6/bin/cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking for /opt/developerstudio12.6/bin/cc option to produce PIC... -KPIC -DPIC checking if /opt/developerstudio12.6/bin/cc PIC flag -KPIC -DPIC works... yes checking if /opt/developerstudio12.6/bin/cc static flag -Bstatic works... yes checking if /opt/developerstudio12.6/bin/cc supports -c -o file.o... yes checking if /opt/developerstudio12.6/bin/cc supports -c -o file.o... (cached) yes checking whether the /opt/developerstudio12.6/bin/cc linker (/usr/ccs/bin/sparcv9/ld -64) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for a BSD-compatible install... ./install-sh -c checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for int8_t... yes checking for int16_t... yes checking for int32_t... yes checking for int64_t... yes checking for intptr_t... yes checking for uint8_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for uint64_t... yes checking for uintptr_t... yes checking for sys/types.h... (cached) yes checking for stdlib.h... (cached) yes checking for stdint.h... (cached) yes checking for inttypes.h... (cached) yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for fdatasync... yes checking for gmtime_r... yes checking for isnan... yes checking for localtime_r... yes checking for localtime_s... no checking for malloc_usable_size... no checking for strchrnul... no checking for usleep... yes checking for utime... yes checking for pread... yes checking for pread64... no checking for pwrite... yes checking for pwrite64... no checking for tclsh8.7... no checking for tclsh8.6... no checking for tclsh8.5... tclsh8.5 configure: Version set to 3.24 configure: Release set to 3.24.0 configure: Version number set to 3024000 checki
[sqlite] which building sqlite-src-3240000 I was surprised to see "make test" fail
Seems to compile fine and yet "gmake test" failed with a less then helpful "Error 2" : . . . sqlite3.c: "sqlite3.c", line 20826: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) "sqlite3.c", line 52491: warning: statement not reached (E_STATEMENT_NOT_REACHED) gmake: *** [Makefile:1161: testfixture] Error 2 Configure was trivial and seems fine : ./configure --enable-shared --enable-static --enable-readline --enable-threadsafe Not sure if perhaps I am doing something blatently wrong. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] building sqlite-src-3240000 I was surprised to see "make test" fail
Seems to compile fine and yet "gmake test" failed with a less then helpful "Error 2" : . . . sqlite3.c: "sqlite3.c", line 20826: warning: implicit function declaration: localtime_r (E_NO_IMPLICIT_DECL_ALLOWED) "sqlite3.c", line 52491: warning: statement not reached (E_STATEMENT_NOT_REACHED) gmake: *** [Makefile:1161: testfixture] Error 2 Configure was trivial and seems fine : ./configure --enable-shared --enable-static --enable-readline --enable-threadsafe Not sure if perhaps I am doing something blatently wrong. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to convert SQL file into database when a column value is Inf?
On 06/13/2018 12:35 PM, skywind mailing lists wrote: Hi Ryan, my problem is that I use the "most safest" mode that exists for SQLite and it still fails… Therefore, I need to know why it fails. I have been watching this from a distance and all I can think is : 1) what do you mean by a "SQL file"? Do you mean a backup file of some type? 2) what was the source database type ? 3) why not simply remove the offending "Inf" data? Really you need someone to look over the data from top to bottom and then render the data into a database for you. In any format possible given that the data may be trash. Then look at the result and determine if it will work for you or not. Why have not done this simple step? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
On 6/8/18 2:39 AM, Simon Slavin wrote: On 8 Jun 2018, at 7:19am, Ron Yorston wrote: Meh. *All* programmers of a certain age wrote their own web server. Zawinski's Law: "Every program attempts to expand until it can read mail." updated for an age where everything is web-based, not email-based. Well done. Yes. This may actually be a true statement in nearly all cases. dc ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
On 6/8/18 2:33 AM, Scott Robison wrote: On Fri, Jun 8, 2018, 12:19 AM Ron Yorston wrote: Dennis Clarke wrote: On 6/7/18 9:59 PM, Richard Hipp wrote: On 6/7/18, Scott Doctor wrote: Just out of curiosity, is the sqlite website using nginx or apache as the server? None of the above. The web server is one that I wrote myself You're level of cool just jumped to UNIX silverback level :-) Meh. *All* programmers of a certain age wrote their own web server. But did they write it with their own text editor? :) Really .. a subset of vi ? Let's all just agree, it is pretty damn cool. dc ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
On 6/7/18 10:29 PM, Simon Slavin wrote: On 8 Jun 2018, at 2:59am, Richard Hipp wrote: The web server is one that I wrote myself Yeah. And it doesn't return a "Server:" header. How do you NOT love that? :-) dc ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
On 6/7/18 9:59 PM, Richard Hipp wrote: On 6/7/18, Scott Doctor wrote: Just out of curiosity, is the sqlite website using nginx or apache as the server? None of the above. The web server is one that I wrote myself You're level of cool just jumped to UNIX silverback level :-) Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite.org website is now HTTPS-only
On 6/7/18 5:34 PM, Bob Friesenhahn wrote: On Thu, 7 Jun 2018, Warren Young wrote: Yes, I know that, but it does solve the other likely problem when using a too-old system with HTTPS, being an inability for the client and server to agree on a mutually-supported encryption suite. With all of the security vulnerabilities found in encryption algorithms, hashing algorithms, and libraries over the past 9 years, there’s a fair chance Lenny’s OpenSSL won’t be able to talk to the TLS implementation on sqlite.org even with the CA issue solved. In this case, we already heard that Lenny’s wget is able to access the web site if server certificate checks are disabled. It is much easier to add to the certificates used by the system given that wget already works. Bob Merely my nickle's worth of thoughts here but I think you can go to a Debian 9 system and tarball the contents of /etc/ssl/certs and then drop them into any system. There should be a ssl.cnf file kicking around as well if that helps. Also wget can be given --ca-directory=/etc/ssl/certs as an option if necessary. Should be if wget is linked with openssl correctly. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Multi threaded readers on memory sqlite cannot scale
On 05/13/2018 11:57 AM, Kevin O'Gorman wrote: The arguments here are simplified Will you stop top posting please? I am trying to follow along here about some x86 boxen stuff but you are top posting madly. Also is that a single socket machine with a single big memory bank or is it NUMA and multiple sockets or is it just a single motherboard unit? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] OR statement in LIKE
On 05/10/2018 01:48 PM, David Raymond wrote: Insert usual comment of "the more you add, the less 'Lite' it becomes" Saw this and thought "brilliant". Exactly. The UNIX way is to do one thing and do it well and move on. Not seventy five things poorly. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Are you getting spam when you post to sqlite-users ?
"Banishing" means configuring IP filters on the server to silently discard any and all IP packets that originate from the targeted range of IP addresses. This is the best method that I have ever used and I can tell you that your ipfilter rules can get quite long using this approach. In truth I banish ALL registered subnets from certain areas of the world and then life goes on. Entire continents blocked. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-autoconf-3200100 : Where is the test suite for sqlite ?
On 14/09/17 02:00 PM, Richard Hipp wrote:
On 9/14/17, Dennis Clarke <dcla...@blastwave.org> wrote:
RE : sqlite-autoconf-3200100
The sqlite-autoconf-3200100 tarball strips out all the tests. Maybe
grab a copy of the canonical source code
(https://sqlite.org/2017/sqlite-src-3200100.zip) and then run
"./configure; make test".
A few tests fail on Debian linux 4.15.0-2-powerpc64 where we have
uname -m says "ppc64" :
.
.
.
Time: zerodamage.test 63 ms
! zipfile-2.4a.2.1 expected: [dirname2 16877 1523740919 {}
dirname2/file1.txt 33188 1523740919 abcdefghijklmnop dirname3 16877
1523740919 {}]
! zipfile-2.4a.2.1 got: [dirname2 17901 1523740919 {}
dirname2/file1.txt 33188 1523740919 abcdefghijklmnop dirname3 17901
1523740919 {}]
! zipfile-2.4a.2.2 expected: [dirname2 16877 1523740919 {}
dirname2/file1.txt 33188 1523740919 abcdefghijklmnop dirname3 16877
1523740919 {}]
! zipfile-2.4a.2.2 got: [dirname2 17901 1523740919 {}
dirname2/file1.txt 33188 1523740919 abcdefghijklmnop dirname3 17901
1523740919 {}]
Time: zipfile.test 1172 ms
Time: zipfile2.test 76 ms
SQLite 2018-04-10 17:39:29
4bb2294022060e61de7da5c227a69ccd846ba330e31626ebcd59a94efd148b3b
2 errors out of 144935 tests on nix Linux 64-bit big-endian
!Failures on these tests: zipfile-2.4a.2.1 zipfile-2.4a.2.2
All memory allocations freed - no leaks
Maximum memory usage: 9262760 bytes
Current memory usage: 0 bytes
Number of malloc() : -1 calls
gmake: *** [Makefile:1187: tcltest] Error 1
Command exited with non-zero status 2
nix$
Is there a way to gather more details from the failed tests?
Dennis
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Running sums and averages
Memory is cheap and most servers have plenty. Processors are fast and most servers have multiple with many cores. Select the entire table of columns you need into memory. Write a little code. No it won't scale very well into millions of rows but I could easily run a test and I will bet many mnay many dollars that processing the sums in memory is orders of magnitude faster than SQL. You shouldn't even need to read the entire table (or view) into memory: just read row-by-row, and for each field, keep a running total and the count of non-NULL values. From these you can calculate your total and both types of average. Graham yes .. that is even better ! Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Running sums and averages
Is there anything I can do to reduce the time taken? 123456789+123456789+123456789+123456789+123456789+123456789+123456789+12 > < Simon correctly advised > > Do it in your favourite programming language rather than SQL. Let me be even more clear : Memory is cheap and most servers have plenty. Processors are fast and most servers have multiple with many cores. Select the entire table of columns you need into memory. Write a little code. No it won't scale very well into millions of rows but I could easily run a test and I will bet many mnay many dollars that processing the sums in memory is orders of magnitude faster than SQL. Dennis ps: if your db is MySQL or Oracle db then the problem is trivial with the C API ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-autoconf-3200100 : Where is the test suite for sqlite ?
On 09/14/2017 02:00 PM, Richard Hipp wrote: On 9/14/17, Dennis Clarke <dcla...@blastwave.org> wrote: RE : sqlite-autoconf-3200100 Dear maillist : After doing a typical configure and compile on a 64-bit PPC arch linux server I was very very surprised to see : ppc64$ /usr/local/bin/gmake installcheck gmake: Nothing to be done for `installcheck'. ppc64$ /usr/local/bin/gmake check gmake: Nothing to be done for `check'. Is there no way to confirm that the compile results in a good and valid output ? The sqlite-autoconf-3200100 tarball strips out all the tests. convenient :-\ Maybe grab a copy of the canonical source code (https://sqlite.org/2017/sqlite-src-3200100.zip) and then run "./configure; make test". OKay, thank you, I will assume http://sqlite.org/2017/sqlite-autoconf-3200100.tar.gz is the same thing. Hopefully the configure script is in there and it all just builds out of the box. I will let you know as I saw this : http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2017-September/074946.html Also https://bugs.gentoo.org/630818 I figured the same issue would be in PPC64 but alas the tests were absent. Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite-autoconf-3200100 : Where is the test suite for sqlite ?
RE : sqlite-autoconf-3200100 Dear maillist : After doing a typical configure and compile on a 64-bit PPC arch linux server I was very very surprised to see : ppc64$ /usr/local/bin/gmake installcheck gmake: Nothing to be done for `installcheck'. ppc64$ /usr/local/bin/gmake check gmake: Nothing to be done for `check'. Is there no way to confirm that the compile results in a good and valid output ? Dennis ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
