SQLite Forum

Timeline
Login

16 forum posts by user jiang446079653

2021-05-17
07:30 Post: Bug report: strange error message in cte and window function (artifact: aeb2124a8a user: jiang446079653)

Hello,

I used my fuzzing tool to test sqlite of latest version, and found that it returned stange error message when processing a sql.

Test command:

rm test.db; ./sqlite3 test.db < fuzz.sql

The content of fuzz.sql:

create table t_sa ( c_muyat INTEGER NOT NULL, c_d4u TEXT , c_lngdt TEXT NOT NULL, c_c3v INTEGER , primary key(c_c3v), unique(c_muyat), check(1=1) );

WITH cte_0 AS (select ref_0.c_muyat as c1 from t_sa as ref_0 ) select LAG(cast(cast(null as INTEGER) as INTEGER)) over gen8fjew as c0 from t_sa as ref_5 window gen8fjew as ( partition by (select c1 from cte_0 order by c1 limit 1 offset 4));

The returned error message is:

Error: near line 11: no such table: cte_0

It seems to be a bug since cte_0 has been created.

03:32 Post: Bug report: strange error message in trigger (artifact: acb9b77141 user: jiang446079653)

Hello,

I used my fuzzing tool to test sqlite of latest version, and found that it returned stange error message when processing a sql.

Test command:

rm test.db; ./sqlite3 test.db

It normally run when processing the first three SQL statements, and create the trigger successfully.

sqlite> create table t_sa ( ...> c_muyat INTEGER NOT NULL, ...> c_d4u TEXT , ...> c_lngdt TEXT NOT NULL, ...> c_c3v INTEGER , ...> primary key(c_c3v), ...> unique(c_muyat), ...> check(1=1) ...> );

sqlite> create table t_k ( ...> c_ak8 INTEGER , ...> c_scig TEXT NOT NULL, ...> c_rcbc INTEGER , ...> c_n07c5 INTEGER NOT NULL, ...> primary key(c_rcbc), ...> unique(c_rcbc) ...> );

sqlite> create trigger t_i4bwy after delete on t_sa ...> for each row ...> begin ...> delete from t_sa ...> where ...> (case when t_sa.c_d4u <> ( ...> select ...> t_sa.c_lngdt as c0 ...> from ...> t_k as ref_8 ...> where t_sa.c_c3v IS NOT t_sa.c_muyat ...> window oamat7fzf as ( partition by t_sa.c_d4u order by t_sa.c_d4u,t_sa.c_d4u asc)) then t_sa.c_d4u else t_sa.c_d4u end ...> not like 'so8%pjs'); ...> end;

When it process the fourth statement:

sqlite> alter table t_sa rename column c_muyat to c_dg;

It returns a error message:

Error: error in trigger t_i4bwy: no such column: t_sa.c_d4u

However, I do change the name of c_muyat instead of c_d4u. Maybe its error message is wrong.

If there is truly some problems in the trigger, I think it should returns error message when I creates the trigger, not when I alter the column name.

2021-04-23
11:38 Reply: Bug report: reachable assertion in zipfile module (artifact: 55e4fe92b0 user: jiang446079653)

Thanks for your confirming

2021-04-22
12:52 Post: Bug report: reachable assertion in zipfile module (artifact: d82289d69f user: jiang446079653)

Hello,

I used my fuzzing tool to test sqlite of latest version, and found a reachable assertion in zipfile module.

Test command:


rm test.db; ./sqlite3 test.db < fuzz.sql

` Here is the output:

sqlite3: ../shell.c:6660: zipfileMtimeToDos: Assertion `mUnixTime<315507600 || mUnixTime==zipfileMtime(pCds) || ((mUnixTime % 2) && mUnixTime-1==zipfileMtime(pCds))' failed.
Aborted

` Here is the content of the simplified fuzz.sql, which can also trigger the assertion:

select zipfile(0,0,9223372036854775808,0);
2020-05-19
10:29 Reply: DATA RACE: Found in sqlite3.c (artifact: fcc334e375 user: jiang446079653)

I think it is a real race because I have reproduced it. Please help me confirm it.

2020-05-14
12:25 Reply: DATA RACE: Found in sqlite3.c (artifact: c7a5d94288 user: jiang446079653)

Could you confirm this race? Because I have successfully reproduced this race by using breakpoints, I think there may be some problems in the file locks.

2020-05-13
10:42 Reply: DATA RACE: Found in sqlite3.c (artifact: 24bf64bde6 user: jiang446079653)

I think there may be some problem in your file locks.

To check whether the race is real, I set breakpoints before these two accesses when they are running in the call stack described above. I find that the breakpoints can be activated simultaneously, and the address of race variables are same. I think these result can prove that the race actually happens. So these accesses is not serialized successfully.

2020-05-03
02:00 Reply: DATA RACE 2: Found in sqlite3.c (artifact: a090f9ccfe user: jiang446079653)

Yes, you are right.

Thanks for your response!!

01:59 Reply: DATA RACE: Found in sqlite3.c (artifact: 6492584deb user: jiang446079653)

Yes, you are right. File locks is not considered.

Thanks for your response.

2020-05-02
07:30 Reply: DATA RACE 3: Found in sqlite3.c (artifact: 4b2d497213 user: jiang446079653)

What do you think about this data race?

07:29 Reply: DATA RACE 2: Found in sqlite3.c (artifact: 6a53280ac2 user: jiang446079653)

What do you think about this data race?

07:28 Reply: DATA RACE: Found in sqlite3.c (artifact: fbeb5ea0b9 user: jiang446079653)

What do you think about this data race?

2020-04-29
03:32 Post: DATA RACE 2: Found in sqlite3.c (artifact: cc3d38e7bd user: jiang446079653)

Dear SQLite developers:

I used my fuzz-testing tool, connzer, to detect data race in SQLite. Here is a data race found by connzer. I wish you can help me check whether it is a real race, thanks!!

The following is the race report.

Race report

Version: 3.30.1

Race object: pShmNode->pShmMutex

Thread 1:

Access: pShmNode->pShmMutex = sqlite3_mutex_alloc(SQLITE_MUTEX_FAST);

Line number: sqlite3.c, 37258

Call stack:

  1. unixOpenSharedMemory()
  2. unixShmMap()
  3. sqlite3OsShmMap()
  4. walIndexPageRealloc()
  5. walIndexPage()
  6. walIndexReadHdr()
  7. walTryBeginRead()
  8. sqlite3WalBeginReadTransaction()
  9. pagerBeginReadTransaction()
  10. sqlite3PagerSharedLock()
  11. lockBtree()
  12. sqlite3BtreeBeginTrans()
  13. sqlite3VdbeExec()
  14. sqlite3Step()
  15. sqlite3_step()
  16. sqlite3_exec()
  17. sql_script_x()
  18. walthread2_thread()
  19. launch_thread_main()

Lock: unixEnterMutex()

Thread 2:

Access: sqlite3_mutex_enter(pShmNode->pShmMutex);

Line number: sqlite3.c; 37305

Call stack:

  1. unixOpenSharedMemory()
  2. unixShmMap()
  3. sqlite3OsShmMap()
  4. walIndexPageRealloc()
  5. walIndexPage()
  6. walIndexReadHdr()
  7. walTryBeginRead()
  8. sqlite3WalBeginReadTransaction()
  9. pagerBeginReadTransaction()
  10. sqlite3PagerSharedLock()
  11. lockBtree()
  12. sqlite3BtreeBeginTrans()
  13. sqlite3BtreeSetVersion()
  14. sqlite3VdbeExec()
  15. sqlite3Step()
  16. sqlite3_step()
  17. sqlite3_exec()
  18. sql_script_x()
  19. walthread2_thread()
  20. launch_thread_main()

Lock: sqlite3_mutex_enter(pShmNode->pShmMutex)

Impact: This race may cause serious consequence: if the race access in thread 2 is executed before the race access in thread 1, pShmNode->pShmMutex in unixOpenSharedMemory() in thread 2 will be uninitialized, and sqlite3_mutex_enter(pShmNode->pShmMutex) will cause crash.

My fuzzer finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.

03:22 Post: DATA RACE 3: Found in sqlite3.c (artifact: 339b26bbf4 user: jiang446079653)

Dear SQLite developers:

I used my fuzz-testing tool, connzer, to detect data race in SQLite. Here is a data race found by connzer. I wish you can help me check whether it is a real race, thanks!!

The following is the race report.

Race report

Version: 3.30.1

Race object: pDbFd->pInode->pShmNode

Thread 1:

Access: pDbFd->pInode->pShmNode = pShmNode;

Line number: sqlite3.c; 37255

Call stack:

  1. unixOpenSharedMemory()
  2. unixShmMap()
  3. sqlite3OsShmMap()
  4. walIndexPageRealloc()
  5. walIndexPage()
  6. walIndexReadHdr()
  7. walTryBeginRead()
  8. sqlite3WalBeginReadTransaction()
  9. pagerBeginReadTransaction()
  10. sqlite3PagerSharedLock()
  11. lockBtree()
  12. sqlite3BtreeBeginTrans()
  13. sqlite3InitOne()
  14. sqlite3Init()
  15. sqlite3ReadSchema()
  16. sqlite3Pragma()
  17. yy_reduce()
  18. sqlite3Parser()
  19. sqlite3RunParser()
  20. sqlite3Prepare()
  21. sqlite3LockAndPrepare()
  22. sqlite3_prepare_v2()
  23. sqlite3_exec()
  24. opendb_x()
  25. walthread1_thread()
  26. launch_thread_main()

Lock: unixEnterMutex();

Thread 2:

Access: pShmNode = pFile->pInode->pShmNode;

Line number: sqlite3.c, 36994

Call stack:

  1. unixShmSystemLock()
  2. unixShmLock()
  3. sqlite3OsShmLock()
  4. walLockExclusive()
  5. walIndexReadHdr()
  6. walTryBeginRead()
  7. sqlite3WalBeginReadTransaction()
  8. pagerBeginReadTransaction()
  9. sqlite3PagerSharedLock()
  10. lockBtree()
  11. sqlite3BtreeBeginTrans()
  12. sqlite3InitOne()
  13. sqlite3Init()
  14. sqlite3Pragma()
  15. sqlite3ReadSchema()
  16. yy_reduce()
  17. sqlite3Parser()
  18. sqlite3RunParser()
  19. sqlite3Prepare()
  20. sqlite3LockAndPrepare()
  21. sqlite3_prepare_v2()
  22. sqlite3_exec()
  23. opendb_x()
  24. walthread1_ckpt_thread()
  25. launch_thread_main()

Lock: sqlite3_mutex_enter(pShmNode->pShmMutex);

Impact: This race may cause serious consequence: if the race access in thread 2 is executed before the race access in thread 1, pShmNode in unixShmSystemLock() in thread 2 will become NULL, and pShmNode->nRef will cause Null dereference.

My fuzzer finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.

02:14 Post: DATA RACE: Found in sqlite3.c (artifact: 5b26d9dd74 user: jiang446079653)

Dear SQLite developers:

I used my fuzz-testing tool, connzer, to detect data race in SQLite. Here is a data race found by connzer. I wish you can help me check whether it is a real race, thanks!!

The following is the race report.

Race report

Race object: pInfo->nBackfill

Thread 1:

Access: pInfo->nBackfill==pWal->hdr.mxFrame

Line number: sqlite3.c, 61048

Call stack:

  1. walTryBeginRead()
  2. sqlite3WalBeginReadTransaction()
  3. pagerBeginReadTransaction()
  4. sqlite3PagerSharedLock()
  5. lockBtree()
  6. sqlite3BtreeBeginTrans()
  7. sqlite3VdbeExec()
  8. sqlite3Step()
  9. sqlite3_step()
  10. execsql_i64_x()
  11. walthread3_thread()
  12. launch_thread_main()

Lock:

  • None

Thread 2:

Access: pInfo->nBackfill = 0;

Line number: sqlite3.c, 60269

Call stack:

  1. walRestartHdr()
  2. walRestartLog()
  3. sqlite3WalFrames()
  4. pagerWalFrames()
  5. sqlite3PagerCommitPhaseOne()
  6. sqlite3BtreeCommitPhaseOne()
  7. vdbeCommit()
  8. sqlite3VdbeHalt()
  9. sqlite3VdbeExec()
  10. sqlite3_step->sqlite3Step()
  11. execsql_i64_x()
  12. walthread3_thread()
  13. launch_thread_main()

Lock:

  • None

My fuzzer finds that these 2 accesses can be executed concurrently, and they are not protected by any lock, so my fuzzer report this race.

01:59 Post: DATA RACE: Found in sqlite3.c (artifact: 8cbc6f48e7 user: jiang446079653)

Dear SQLite developers:

I used my fuzz-testing tool, connzer, to detect data race in SQLite. Here is a data race found by connzer. I wish you can help me check whether it is a real race, thanks!!

The following is the race report.

Race report

Race object: pShmNode->pShmMutex

Thread 1:

Access: pShmNode->pShmMutex = sqlite3_mutex_alloc(SQLITE_MUTEX_FAST);

Line number: sqlite3.c, 37258

Call stack:

  1. unixOpenSharedMemory()
  2. unixShmMap()
  3. sqlite3OsShmMap()
  4. walIndexPageRealloc()
  5. walIndexPage()
  6. walIndexReadHdr()
  7. walTryBeginRead()
  8. sqlite3WalBeginReadTransaction()
  9. pagerBeginReadTransaction()
  10. sqlite3PagerSharedLock()
  11. lockBtree()
  12. sqlite3BtreeBeginTrans()
  13. sqlite3VdbeExec()
  14. sqlite3Step()
  15. sqlite3_step()
  16. sqlite3_exec()
  17. sql_script_x()
  18. walthread2_thread()
  19. launch_thread_main()

Lock:

  1. unixEnterMutex()

Thread 2:

Access: sqlite3_mutex_leave(pShmNode->pShmMutex);

Line number: sqlite3.c; 37308

Call stack:

  1. unixOpenSharedMemory()
  2. unixShmMap()
  3. sqlite3OsShmMap()
  4. walIndexPageRealloc()
  5. walIndexPage()
  6. walIndexReadHdr()
  7. walTryBeginRead()
  8. sqlite3WalBeginReadTransaction()
  9. pagerBeginReadTransaction()
  10. sqlite3PagerSharedLock()
  11. lockBtree()
  12. sqlite3BtreeBeginTrans()
  13. sqlite3BtreeSetVersion()
  14. sqlite3VdbeExec()
  15. sqlite3Step()
  16. sqlite3_step()
  17. sqlite3_exec()
  18. sql_script_x()
  19. walthread2_thread()
  20. launch_thread_main()

Lock:

  1. sqlite3_mutex_enter(pShmNode->pShmMutex)

My fuzzer finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.