SQLite Forum

memory leaks in sqlite3.c:23545
Login

memory leaks in sqlite3.c:23545

(1.1) By puppet2333 (zxc8263735) on 2020-05-27 14:23:44 edited from 1.0 [link]

Version: SQLite version 3.32.0 2020-04-06 18:16:31

OS: Ubuntu 16.04 LTS

POC:  https://github.com/puppet-meteor/NLP_POC/blob/master/sqlite3/POC_6_000613

cmd: ./sqlite3 < POC 

ASAN log:

=================================================================
==1102==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 112 byte(s) in 1 object(s) allocated from:

    #0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x4616f5 in sqlite3MemMalloc ../sqlite3.c:23545
    #2 0x4626d9 in mallocWithAlarm ../sqlite3.c:27427
    #3 0x46281e in sqlite3Malloc ../sqlite3.c:27457
    #4 0x462faf in sqlite3Realloc ../sqlite3.c:27627
    #5 0x4631a3 in sqlite3_realloc64 ../sqlite3.c:27684
    #6 0x43a5e9 in import_append_char ../shell.c:13151
    #7 0x44b2b5 in do_meta_command ../shell.c:16340
    #8 0x455fb1 in process_input ../shell.c:18527
    #9 0x4588e6 in main ../shell.c:19330
    #10 0x7ffff617c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s)

(2) By puppet2333 (zxc8263735) on 2020-05-27 06:07:02 in reply to 1.0 [link]

the the ASAN logs on the state-of-the-art version 3.32.1 2020-05-25 16:19:56 are as follows:



=================================================================
==2164==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 104 byte(s) in 1 object(s) allocated from:

    #0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x462874 in sqlite3MemMalloc /data3/ASAN2/sqlite-src-3320100/ASAN/sqlite3.c:23627
    #2 0x4637ab in mallocWithAlarm /data3/ASAN2/sqlite-src-3320100/ASAN/sqlite3.c:27519
    #3 0x4638f0 in sqlite3Malloc /data3/ASAN2/sqlite-src-3320100/ASAN/sqlite3.c:27549
    #4 0x464081 in sqlite3Realloc /data3/ASAN2/sqlite-src-3320100/ASAN/sqlite3.c:27719
    #5 0x46423e in sqlite3_realloc64 /data3/ASAN2/sqlite-src-3320100/ASAN/sqlite3.c:27778
    #6 0x43b0b2 in import_append_char /data3/ASAN2/sqlite-src-3320100/ASAN/shell.c:13283
    #7 0x44bf9c in do_meta_command /data3/ASAN2/sqlite-src-3320100/ASAN/shell.c:16507
    #8 0x457078 in process_input /data3/ASAN2/sqlite-src-3320100/ASAN/shell.c:18718
    #9 0x459a68 in main /data3/ASAN2/sqlite-src-3320100/ASAN/shell.c:19529
    #10 0x7ffff648582f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 104 byte(s) leaked in 1 allocation(s).











The relevant codes in sqlite3.c:

```
static void *sqlite3MemMalloc(int nByte){
#ifdef SQLITE_MALLOCSIZE
  void *p;
  testcase( ROUND8(nByte)==nByte );
  p = SQLITE_MALLOC( nByte );                  \\ line 23627
  if( p==0 ){
    testcase( sqlite3GlobalConfig.xLog!=0 );
    sqlite3_log(SQLITE_NOMEM, "failed to allocate %u bytes of memory", nByte);
  }
  return p;
#else
  sqlite3_int64 *p;
  assert( nByte>0 );
  testcase( ROUND8(nByte)!=nByte );
  p = SQLITE_MALLOC( nByte+8 );
  if( p ){
    p[0] = nByte;
    p++;
  }else{
    testcase( sqlite3GlobalConfig.xLog!=0 );
    sqlite3_log(SQLITE_NOMEM, "failed to allocate %u bytes of memory", nByte);
  }
  return (void *)p;
#endif
}
```

(3) By anonymous on 2020-05-27 08:47:26 in reply to 1.0 [link]

Your links are broken. Either stop using Markdown/Fossil Wiki markup style or stop using underscores in links or learn to properly add links in Markdown/Fossil Wiki. <verbatim>[https://github.com/puppet-meteor/NLP_POC/blob/master/sqlite3/|like this]</verbatim>

[https://github.com/puppet-meteor/NLP_POC/blob/master/sqlite3/|like this].

(4) By Stephan Beal (stephan) on 2020-05-27 09:01:25 in reply to 3 [link]

> Your links are broken. Either ...

Or, more simply change the post format to "plain text."

That said: leaks detected by analyzers are sometimes wrong, and very little software in the world is as well-vetted and widely-deployed as sqlite is. If the OP would like the reports to be taken seriously, *proof* of a leak is needed, in the form of code which demonstrates it, rather than the pasted-in output from an automated tool.

(5) By Larry Brasfield (LarryBrasfield) on 2020-05-28 23:10:16 in reply to 1.1 [link]

Interestingly, when I jam that same input into a leak-instrumented build of sqlite3.exe v3.32.1 (using MSVC and its CRT leak detection aid), then exit, I see a single leak of a 24 byte block.  I will look into this a bit further and report more when I know more.

(6) By anonymous on 2020-05-29 18:36:30 in reply to 4 [link]

> If the OP would like the reports to be taken seriously, proof of a leak is needed, in the form of code which demonstrates it, rather than the pasted-in output from an automated tool.

Leak reports must be taken seriously, especially produced by common tools (in this case looks like it's `gcc` sanitizer). 

The burden of dis-proof lies squarely on the developer!

No one is expecting users to "proof" the leak... manually. I'm already glad the reporting user was able to fuzz the input to trigger the sanitizer report.

Now it's the turn for an interested/responsible/able developer to properly follow on, not just blindly dismiss this as a "false-positive".

(7) By anonymous on 2020-05-29 19:36:49 in reply to 1.1

Building on the discovery in [forumpost/9a0ee040bc](https://sqlite.org/forum/forumpost/9a0ee040bc). Below is the patch @[6a01e4c444b072e3](https://www.sqlite.org/src/info/6a01e4c444b072e3) that seems to clear the leak.

It may be prudent to audit the code for more instances of `goto` jumps ... 


```
Index: src/shell.c.in
==================================================================
--- src/shell.c.in
+++ src/shell.c.in
@@ -8042,10 +8042,11 @@
     }
     sqlite3_free(zSql);
     if( rc ){
       if (pStmt) sqlite3_finalize(pStmt);
       utf8_printf(stderr,"Error: %s\n", sqlite3_errmsg(p->db));
+      sqlite3_free(sCtx.z);
       xCloser(sCtx.in);
       rc = 1;
       goto meta_command_exit;
     }
     nCol = sqlite3_column_count(pStmt);
@@ -8071,10 +8072,11 @@
     rc = sqlite3_prepare_v2(p->db, zSql, -1, &pStmt, 0);
     sqlite3_free(zSql);
     if( rc ){
       utf8_printf(stderr, "Error: %s\n", sqlite3_errmsg(p->db));
       if (pStmt) sqlite3_finalize(pStmt);
+      sqlite3_free(sCtx.z);
       xCloser(sCtx.in);
       rc = 1;
       goto meta_command_exit;
     }
     needCommit = sqlite3_get_autocommit(p->db);

```