Test error in oserror-2.1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Test error in oserror-2.1.1

Free Ekanayaka
Hello,

I've tried to run the quicktest suite for SQLite 3.22.0 on Linux (kernel
version 4.13.0), and when it executes test/oserror.test I get errors:

oserror-1.1.1... Ok
oserror-1.1.2... Ok
oserror-1.1.3... Ok
oserror-1.2.1... Ok
oserror-1.2.2... Ok
oserror-1.3.1... Ok
oserror-1.3.2... Ok
oserror-1.4.1... Ok
oserror-1.4.2... Ok
oserror-2.1.1...
! oserror-2.1.1 expected: [1 {disk I/O error}]
! oserror-2.1.1 got:      [0 {}]
oserror-2.1.2...
! oserror-2.1.2 expected: [^os_unix.c:\d+: \(\d+\) unlink\(.*test.db-wal\) - ]
! oserror-2.1.2 got:      []
oserror-2.1.3... Ok

After looking at the code in test/oserror.test, I'm confused about how
it could possibly ever pass: as far as I can see and understand, it does
not enable WAL journaling at all:

ifcapable wal {
  do_test 2.1.1 {
    set ::log [list]
    file mkdir test.db-wal
    forcedelete test.db
    list [catch {
      sqlite3 dbh test.db
      execsql { SELECT * FROM sqlite_master } dbh
    } msg] $msg
  } {1 {disk I/O error}}
 
  do_re_test 2.1.2 {
    lindex $::log 0
  } {^os_unix.c:\d+: \(\d+\) unlink\(.*test.db-wal\) - }
  do_test 2.1.3 {
    catch { dbh close }
    forcedelete test.db-wal
  } {}
}

so the file "testdir/test.db-wal" (which the test overrides with a dir)
does never come into play in the testdir/test.db DB that the test opens.

On the contrary, other WAL-related tests (such as test/wal.test) do
enable WAL journaling via "PRAGMA journal_mode = wal".

Any hints?

Thanks
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Test error in oserror-2.1.1

Dan Kennedy-4
On 02/19/2018 01:28 AM, Free Ekanayaka wrote:

> Hello,
>
> I've tried to run the quicktest suite for SQLite 3.22.0 on Linux (kernel
> version 4.13.0), and when it executes test/oserror.test I get errors:
>
> oserror-1.1.1... Ok
> oserror-1.1.2... Ok
> oserror-1.1.3... Ok
> oserror-1.2.1... Ok
> oserror-1.2.2... Ok
> oserror-1.3.1... Ok
> oserror-1.3.2... Ok
> oserror-1.4.1... Ok
> oserror-1.4.2... Ok
> oserror-2.1.1...
> ! oserror-2.1.1 expected: [1 {disk I/O error}]
> ! oserror-2.1.1 got:      [0 {}]
> oserror-2.1.2...
> ! oserror-2.1.2 expected: [^os_unix.c:\d+: \(\d+\) unlink\(.*test.db-wal\) - ]
> ! oserror-2.1.2 got:      []
> oserror-2.1.3... Ok
>
> After looking at the code in test/oserror.test, I'm confused about how
> it could possibly ever pass: as far as I can see and understand, it does
> not enable WAL journaling at all:

When SQLite opens a read or write transaction on a database file zero
bytes in size, it attempts to delete any journal or wal file that is
already present in the file system using unlink() before proceeding. And
any unlink() on a directory should fail with EISDIR, causing the errors
that the test cases are looking for.

Not sure what is going wrong here though. If you try the same test with
the shell tool:

   $ rm -f x.db
   $ mkdir x.db-wal
   $ sqlite3 x.db
   ...
   sqlite> select * from sqlite_master;
   Error: disk I/O error

do you get the I/O error/

Dan.




>
> ifcapable wal {
>    do_test 2.1.1 {
>      set ::log [list]
>      file mkdir test.db-wal
>      forcedelete test.db
>      list [catch {
>        sqlite3 dbh test.db
>        execsql { SELECT * FROM sqlite_master } dbh
>      } msg] $msg
>    } {1 {disk I/O error}}
>    
>    do_re_test 2.1.2 {
>      lindex $::log 0
>    } {^os_unix.c:\d+: \(\d+\) unlink\(.*test.db-wal\) - }
>    do_test 2.1.3 {
>      catch { dbh close }
>      forcedelete test.db-wal
>    } {}
> }
>
> so the file "testdir/test.db-wal" (which the test overrides with a dir)
> does never come into play in the testdir/test.db DB that the test opens.
>
> On the contrary, other WAL-related tests (such as test/wal.test) do
> enable WAL journaling via "PRAGMA journal_mode = wal".
>
> Any hints?
>
> Thanks
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Test error in oserror-2.1.1

Free Ekanayaka
Hi,

Dan Kennedy <[hidden email]> writes:

> On 02/19/2018 01:28 AM, Free Ekanayaka wrote:
>> Hello,
>>
>> I've tried to run the quicktest suite for SQLite 3.22.0 on Linux (kernel
>> version 4.13.0), and when it executes test/oserror.test I get errors:
>>
>> oserror-1.1.1... Ok
>> oserror-1.1.2... Ok
>> oserror-1.1.3... Ok
>> oserror-1.2.1... Ok
>> oserror-1.2.2... Ok
>> oserror-1.3.1... Ok
>> oserror-1.3.2... Ok
>> oserror-1.4.1... Ok
>> oserror-1.4.2... Ok
>> oserror-2.1.1...
>> ! oserror-2.1.1 expected: [1 {disk I/O error}]
>> ! oserror-2.1.1 got:      [0 {}]
>> oserror-2.1.2...
>> ! oserror-2.1.2 expected: [^os_unix.c:\d+: \(\d+\) unlink\(.*test.db-wal\) - ]
>> ! oserror-2.1.2 got:      []
>> oserror-2.1.3... Ok
>>
>> After looking at the code in test/oserror.test, I'm confused about how
>> it could possibly ever pass: as far as I can see and understand, it does
>> not enable WAL journaling at all:
>
> When SQLite opens a read or write transaction on a database file zero
> bytes in size, it attempts to delete any journal or wal file that is
> already present in the file system using unlink() before proceeding. And
> any unlink() on a directory should fail with EISDIR, causing the errors
> that the test cases are looking for.
>
> Not sure what is going wrong here though. If you try the same test with
> the shell tool:
>
>    $ rm -f x.db
>    $ mkdir x.db-wal
>    $ sqlite3 x.db
>    ...
>    sqlite> select * from sqlite_master;
>    Error: disk I/O error
>
> do you get the I/O error/

I believe I found the issue. Apparently if you're using btrfs as file
system, the above error does not occur. I didn't yet investigate why,
but that's what I get from testing it.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users