What version of the TCL library are you linking against?

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

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

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

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.

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
==335088==
rtreedoc3-1.0... Ok
alloc: invalid block: 0x4dc8ea0: ef ef b0
==335088==
==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==
==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==
==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==
==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)

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

Thank you really much for investigating and fixing the test!