Hi,
I have noticed that most of my suggested patch has been applied.
However, the part of
if( 0 == nIn ) {
sqlite3_result_zeroblob(ctx, 0);
fclose(in);
return;
}
got left out somehow. As a result sqlite now throws an out-of-memory
error when dealing with empty files:
$ touch empty ; sqlite3 test.db -Ac empty
ERROR: out of memory
The reason for this is that sqlite3_malloc64(0) will return NULL;
Therefore it looks like there was not enough memory.
Was there a specific reason why this part was not merged?
We could also leave the zeroblob line out so that we get a null result.
Thanks,
Daniel
Am 11.01.2019 16:37 schrieb [email protected]:
Hello,
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
0
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
strange.
When we look at the TRACE file we see:
PRAGMA page_size=512;
SAVEPOINT ar;
DROP TABLE IF EXISTS sqlar;
CREATE TABLE IF NOT EXISTS sqlar(
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 $?
0
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 $?
0
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.
Best,
Daniel
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;
+ }
rewind(in);
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);
}else{
+ sqlite3_result_error_code(ctx, SQLITE_IOERR_READ);
sqlite3_free(pBuf);
}
fclose(in);
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
