Possible bug when executing query
(1) By Yu Liang (LY1598773890) on 2022-10-30 23:10:03 [link] [source]
We encounter a crash when testing
SQLite3. The testing query generates one binary file to the file system, then reads the binary file and triggers the crash.
Since I cannot upload the binary file to the forum, I place them into our Google Drive. The PoC binary file is in: link. The PoC query that reads the binary file and triggers the crash is in: link.
Additionally, we also upload the whole PoC query that generates the binary file and then crash the
SQLite process. The complete PoC query is placed in: link.
Here is some debug information for the crash. The stack trace is:
#0 0x0000000000000000 in ?? () #1 0x0000000000479720 in sqlite3OsUnfetch (id=0x6aba90, iOff=0x0, p=0x0) at sqlite3.c:24924 #2 0x00000000004915c6 in sqlite3PagerSharedLock (pPager=0x6ab910) at sqlite3.c:60480 #3 0x000000000049007e in lockBtree (pBt=0x6a7200) at sqlite3.c:71232 #4 0x000000000044f5d5 in sqlite3BtreeBeginTrans (p=0x6ab3d0, wrflag=0x0, pSchemaVersion=0x7fffffff8704) at sqlite3.c:71624 #5 0x00000000004abcf5 in sqlite3VdbeExec (p=0x6b8f30) at sqlite3.c:93504 #6 0x00000000004556dd in sqlite3Step (p=0x6b8f30) at sqlite3.c:87967 #7 0x000000000044cf57 in sqlite3_step (pStmt=0x6b8f30) at sqlite3.c:88028 #8 0x000000000045d474 in sqlite3_exec (db=0x6a8a20, zSql=0x612738 "SELECT 1 FROM sqlite_schema", xCallback=0x0, pArg=0x0, pzErrMsg=0x0) at sqlite3.c:130963 #9 0x000000000042d74e in recoverExec (p=0x6aeac0, db=0x6a8a20, zSql=0x612738 "SELECT 1 FROM sqlite_schema") at shell.c:13112 #10 0x0000000000408f84 in recoverStep (p=0x6aeac0) at shell.c:15138 #11 0x0000000000408e1a in sqlite3_recover_step (p=0x6aeac0) at shell.c:15364 #12 0x0000000000409205 in sqlite3_recover_run (p=0x6aeac0) at shell.c:15376 #13 0x0000000000436516 in recoverDatabaseCmd (pState=0x7fffffffc7c0, nArg=0x1, azArg=0x7fffffffc410) at shell.c:21689 #14 0x000000000040e322 in do_meta_command (zLine=0x6a67f0 ".r", p=0x7fffffffc7c0) at shell.c:22297 #15 0x0000000000419cef in process_input (p=0x7fffffffc7c0) at shell.c:25462 #16 0x000000000040b9b7 in main (argc=0x1, argv=0x7fffffffdde8) at shell.c:26349 #17 0x00007ffff7ba5083 in __libc_start_main (main=0x409a90 <main>, argc=0x1, argv=0x7fffffffdde8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffddd8) at ../csu/libc-start.c:308 #18 0x000000000040377e in _start ()
When compiled with
UBSAN, the sanitizer outputs the following error:
UndefinedBehaviorSanitizer:DEADLYSIGNAL ==3255061==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ffedf2a94e0 sp 0x7ffedf2a94a8 T3255061) ==3255061==Hint: pc points to the zero page. ==3255061==The signal is caused by a READ memory access. ==3255061==Hint: address points to the zero page. #0 0x0 (<unknown module>) #1 0x41f2fa in __sanitizer::HandleDeadlySignal(void*, void*, unsigned int, void (*)(__sanitizer::SignalContext const&, void const*, __sanitizer::BufferedStackTrace*), void const*) (/home/luy70/Desktop/sqlite_source_fossil/sqlite/sqlite3+0x41f2fa) #2 0x7f68485cd41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) UndefinedBehaviorSanitizer can not provide additional info. SUMMARY: UndefinedBehaviorSanitizer: SEGV (<unknown module>) ==3255061==ABORTING
The bisecting results:
bisect complete 1 BAD 2022-10-30 11:39:47 7660db2a2e9c4f3a 9 BAD 2022-10-26 21:14:21 346a3b12b861ce7b 13 BAD 2022-10-26 18:41:12 a820792548da596e 14 GOOD 2022-10-26 18:04:34 4eef562a00ae988f CURRENT 12 GOOD 2022-10-26 15:40:17 3b5aa50c223ac35c 11 GOOD 2022-10-26 11:11:31 3dfdfb3f12edb3f4 10 GOOD 2022-10-25 08:41:00 9c8df130b8137cb4 8 GOOD 2022-10-20 21:28:31 9d034ef5e1bab7c9 7 GOOD 2022-09-30 20:59:09 aa367a3c97404132 6 GOOD 2022-07-11 14:36:03 44d77a7f807f5dc3 5 GOOD 2022-04-07 14:03:07 5043a3507e078187 4 GOOD 2021-10-05 18:33:38 a7835bead85b1b18 3 GOOD 2020-06-15 14:38:57 d31fd57ea5386682 2 GOOD 2018-05-14 00:41:12 d0f35739af3b226c
Please let us know if you need more debug information. Thank you. :-)
(2) By Yu Liang (LY1598773890) on 2022-10-31 15:56:46 in reply to 1 [link] [source]
In case the developers didn't notice the report, here is a gentle reminder.
Is there any updates on the reported problem? Please let us know if you need further information.
(3) By Yu Liang (LY1598773890) on 2022-11-08 18:57:07 in reply to 1 [link] [source]
I just tested the PoC on the latest version of
7660db2a2e), the problem is still reproducible. In case the developers didn't notice this bug report, here is a gentle reminder.
Thank you for the hard work!
(4) By Richard Hipp (drh) on 2022-11-08 19:25:39 in reply to 3 [source]
There is a fix at check-in d15c9a4a323b825e on 2022-10-31. Test cases were added to TH3 to recreate the problem - though I had to come up with test cases on my own, as nobody I know was ever able to repro the problem using your script.
The line number information in your original report is incorrect. For example, your report says that the 2nd stack frame is at sqlite3.c:17653, but the dbpageUpdate() function spans lines 214208..214273 in version c7750c101d9. The problematic line appears to be 214261, not 17653. I note that 214261 == 3*65536 + 17653. What tool chain are you using that is truncating source line numbers to 16 bits?
I am currently unable to reproduce any new problems in the sqlite_dbpage virtual table. If you have suggestions on how your problem can be recreated, that would be helpful. Can you send a stack trace? Perhaps that will provide a clue.