SQLite Forum

memory leak in /ext/fts5/fts5_vocab.c
Login

memory leak in /ext/fts5/fts5_vocab.c

(1) By YJRUC (YuanjunGongRUC) on 2020-11-08 11:17:40 [source]

In function fts5VocabDisconnectMethod and fts5VocabDestroyMethod in /ext/fts5/fts5_vocab.c, there is a memory leak. Field *zFts5Tbl, *zFts5Db, *db should be freed before statement sqlite3_free(pTab);.

struct Fts5VocabTable {
  sqlite3_vtab base;
  char *zFts5Tbl;                 /* Name of fts5 table */
  char *zFts5Db;                  /* Db containing fts5 table */
  sqlite3 *db;                    /* Database handle */
  Fts5Global *pGlobal;            /* FTS5 global object for this database */
  int eType;                      /* FTS5_VOCAB_COL, ROW or INSTANCE */
};

static int fts5VocabDisconnectMethod(sqlite3_vtab *pVtab){
  Fts5VocabTable *pTab = (Fts5VocabTable*)pVtab;
  sqlite3_free(pTab);
  return SQLITE_OK;
}

static int fts5VocabDestroyMethod(sqlite3_vtab *pVtab){
  Fts5VocabTable *pTab = (Fts5VocabTable*)pVtab;
  sqlite3_free(pTab);
  return SQLITE_OK;
}

(2) By Gunter Hick (gunter_hick) on 2020-11-09 10:26:40 in reply to 1 [link] [source]

This may look plausible at first glance, but to prove a memory leak you would have to show that

1) the fields point to dynamically allocated memory that
2) fts5 is responsible for and 
3) is not already freed before the disconnct/destroy methods are called.

Alternatively you can run a repcase that shows
a) excessive memory growth proportional to the repeat count when executed repeatedly,  or
b) shows "definitely lost" blocks when run under Valgrind or similar tools' control.

(3.1) By Dan Kennedy (dan) on 2020-11-09 11:31:44 edited from 3.0 in reply to 2 [link] [source]

Quite so. In this case the two strings are part of the same memory allocation as the Fts5VocabTable structure freed by the xDestroy() and xDisconnect callbacks:

https://www.sqlite.org/src/artifact/7a071833064dc?&ln=207-218

Dan.