Exitcode and savepoint problems during archiving

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Exitcode and savepoint problems during archiving


I have discovered three potential bugs in sqlite which I think are
somewhat related.

The first one is:

when I run the following command and immediately CTRL-C on it in a
shell, I get:

     $ sqlite3 -cmd ".trace TRACE" db.sqlite -Ac /usr ; echo $?
     ^CERROR: interrupted
     ERROR: no such savepoint: ar

I would have expected a non-zero exitcode but I got a zero exitcode.
Apart from that, it outputs that no such savepoint was found, which is
When we look at the TRACE file we see:

     PRAGMA page_size=512;
     SAVEPOINT ar;
       name TEXT PRIMARY KEY,  -- name of the file
       mode INT,               -- access permissions
       mtime INT,              -- last modification time
       sz INT,                 -- original file size
       data BLOB               -- compressed content
     REPLACE INTO sqlar(name,mode,mtime,sz,data)
         ... ;
     ROLLBACK TO ar;

We see that the savepoint "ar" was created in the second line, but the
rollback to it in the last line failed.
I have replayed this trace ( with some hardcoded insert-data ) and
everything works fine ( exitcode and creation and restoration of the
savepoint). Therefore I think the problem must lie either in the
shellcode or in the archive-module.

The second one is:

when I run this command, I get :

     $ fallocate -l 2G bigfile
     $ sqlite3 db -Ac bigfile ; echo $?

The database file is still small and no file was inserted.
My expectation would be that the sqlite command fails or, at least, that
I get some error message.

The third one is:

when I run this command, I get :

     $ echo test > testfile
     $ chmod -r -w testfile
     $ sqlite3 db -Ac testfile ; echo $?

Again, my assumption would be that the command fails or that I get an
error message.

I think the following patch would strengthen the fileio extension
against some disk/memory errors.
My belief is, that the second and third bug can be fixed with this
patch, but not the first one.



diff --git a/ext/misc/fileio.c b/ext/misc/fileio.c
index 2219aafa0..c8d5cd2e5 100644
--- a/ext/misc/fileio.c
+++ b/ext/misc/fileio.c
@@ -127,16 +127,39 @@ static void readFileContents(sqlite3_context *ctx,
const char *zName){
    FILE *in;
    long nIn;
    void *pBuf;
+  sqlite3 * db;
+  int blobLimit;

+  db = sqlite3_context_db_handle(ctx);
+  blobLimit = sqlite3_limit(db,SQLITE_LIMIT_LENGTH,-1);
    in = fopen(zName, "rb");
-  if( in==0 ) return;
+  if( in==0 ) {
+    sqlite3_result_error_code(ctx, SQLITE_IOERR);
+    return;
+  }
    fseek(in, 0, SEEK_END);
    nIn = ftell(in);
+  if( 0 == nIn ) {
+    sqlite3_result_zeroblob(ctx, 0);
+    fclose(in);
+    return;
+  }
+  if( blobLimit < nIn ) {
+    sqlite3_result_error_code(ctx, SQLITE_TOOBIG);
+    fclose(in);
+    return;
+  }
    pBuf = sqlite3_malloc( nIn );
-  if( pBuf && 1==fread(pBuf, nIn, 1, in) ){
+  if (pBuf == NULL) {
+    sqlite3_result_error_nomem(ctx);
+    fclose(in);
+    return;
+  }
+  if( 1==fread(pBuf, nIn, 1, in) ){
      sqlite3_result_blob(ctx, pBuf, nIn, sqlite3_free);
+    sqlite3_result_error_code(ctx, SQLITE_IOERR_READ);
sqlite-users mailing list
[hidden email]