SQLite Forum

Test suite fails when build configured with --enable-rtree option

Test suite fails when build configured with --enable-rtree option

(1) By zmiklank on 2022-02-22 12:47:25 [source]


I encountered a problem when building the SQLite binary with --enable-rtree option:

../configure --enable-rtree && make && make test

The build ends successfully, however the test suite fails at:

Time: rtreedoc.test 308 ms
Time: rtreedoc2.test 41 ms
alloc: invalid block: 0x55928cabe960: ef ef 40
make: *** [Makefile:1280: tcltest] Aborted (core dumped)
error: Bad exit status from /var/tmp/rpm-tmp.o1lzfX (%build)

I have tried to bisect the issue, and the commit, which it lead me to is this one:

FossilOrigin-Name: 7c82b43b7cdb825f431d3a778f8b34e32666ccb3b067f1f2533d3b3dcca7bdc9

What could please be the problem?

(2) By Richard Hipp (drh) on 2022-02-22 12:58:22 in reply to 1 [link] [source]

What version of the TCL library are you linking against?

(3) By zmiklank on 2022-02-22 13:08:15 in reply to 2 [link] [source]

I have installed TCL 8.6.10 from Fedora's repositories on the system.

(4) By curmudgeon on 2022-02-22 13:11:44 in reply to 3 [link] [source]

I had to install tcl-dev for everything to run smoothly.

(5) By zmiklank on 2022-02-22 13:15:18 in reply to 4 [link] [source]

Thanks for the reply, I also have the tcl-devel installed.

(6) By Richard Hipp (drh) on 2022-02-22 13:27:39 in reply to 1 [link] [source]

I'm unable to reproduce the problem. I've tried multiple versions of Linux, Mac (x64 and ARM), and Windows. This is not a problem we've seen on any platform or build configuration before.

Can you:

  • Tell us what OS are running and on what CPU?
  • Tell us exactly what version of SQLite you are trying to compile
  • Run "valgrind ./testfixture ext/rtree/rtreedoc3.test" and see if that sheds any light on the issue.

(7) By zmiklank on 2022-02-22 14:06:29 in reply to 6 [link] [source]

Thanks for replying,

  • OS is Fedora 35

  • CPU is Intel Core i7-10610U

  • I reproduced this issue on the current master branch, however, when I tried to git-bisect the issue, the first commit, which was invalid was the one I stated above. However I must add, that then the error was not an Abort, only a failed rtree test.

  • Following are the logs from running the Valgrind, this is the output of the current master branch build.

$ valgrind ./testfixture ../ext/rtree/rtreedoc3.test
==335088== Memcheck, a memory error detector
==335088== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==335088== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==335088== Command: ./testfixture ../ext/rtree/rtreedoc3.test
rtreedoc3-1.0... Ok
alloc: invalid block: 0x4dc8ea0: ef ef b0
==335088== Process terminating with default action of signal 6 (SIGABRT): dumping core
==335088==    at 0x4B9F88C: __pthread_kill_implementation (pthread_kill.c:44)
==335088==    by 0x4B526A5: raise (raise.c:26)
==335088==    by 0x4B3C7D2: abort (abort.c:79)
==335088==    by 0x4963533: Tcl_PanicVA (tclPanic.c:123)
==335088==    by 0x49635FE: Tcl_Panic (tclPanic.c:160)
==335088==    by 0x498140F: Ptr2Block (tclThreadAlloc.c:847)
==335088==    by 0x4981B1F: UnknownInlinedFun (tclThreadAlloc.c:408)
==335088==    by 0x4981B1F: TclpFree (tclThreadAlloc.c:389)
==335088==    by 0x467FB0: box_query_destroy (in /home/zuzana/git/sqlite/build/testfixture)
==335088==    by 0x54663C: rtreeFreeCallback (in /home/zuzana/git/sqlite/build/testfixture)
==335088==    by 0x532B46: functionDestroy (in /home/zuzana/git/sqlite/build/testfixture)
==335088==    by 0x533036: sqlite3LeaveMutexAndCloseZombie (in /home/zuzana/git/sqlite/build/testfixture)
==335088==    by 0x532DE2: sqlite3Close (in /home/zuzana/git/sqlite/build/testfixture)
==335088== HEAP SUMMARY:
==335088==     in use at exit: 2,373,175 bytes in 253 blocks
==335088==   total heap usage: 16,953 allocs, 16,700 frees, 19,482,419 bytes allocated
==335088== LEAK SUMMARY:
==335088==    definitely lost: 0 bytes in 0 blocks
==335088==    indirectly lost: 0 bytes in 0 blocks
==335088==      possibly lost: 2,204,813 bytes in 116 blocks
==335088==    still reachable: 168,362 bytes in 137 blocks
==335088==         suppressed: 0 bytes in 0 blocks
==335088== Rerun with --leak-check=full to see details of leaked memory
==335088== For lists of detected and suppressed errors, rerun with: -s
==335088== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted (core dumped)

(8) By Richard Hipp (drh) on 2022-02-22 15:53:44 in reply to 1 [link] [source]

There was an undersized memory allocation in RTREE test logic - not in the SQLite library itself, but rather in additional code we use for testing. It was doing "malloc(8)" when it should of been doing "malloc(16)". This was a long-standing issue that for some reason was never detected by MSAN, ASAN, Valgrind, or any of the other memory-safety testing technologies we use. The problem never appears on Ubuntu, Debian, Win10, Mac, or OpenBSD. I had to spin up a new Fedora 35 Linode to reproduce it.

Fixed now. See check-in 7e3c9594390ac8de

(9) By zmiklank on 2022-02-23 06:57:15 in reply to 8 [link] [source]

Thank you really much for investigating and fixing the test!