I have a lot of possible lost entry from valgrind. What does that mean ? As I am using sqlite and it is well tested. I don't think these are correct entry. What I am doing wrong ?
16 bytes in 1 blocks are possibly lost in loss record 30 of 844
==23027== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==23027== by 0x6525BE: sqlite3MemMalloc (in app_mem.out)
==23027== by 0x63C579: mallocWithAlarm (in app_mem.out)
==23027== by 0x63C904: sqlite3DbMallocRaw (in app_mem.out)
==23027== by 0x6886D6: codeOneLoopStart (in app_mem.out)
==23027== by 0x68A9C8: sqlite3WhereBegin (in app_mem.out)
==23027== by 0x68CC9E: sqlite3Select (in app_mem.out)
==23027== by 0x6A8644: yy_reduce (in app_mem.out)
==23027== by 0x6AAEAC: sqlite3Parser (in app_mem.out)
==23027== by 0x6AB357: sqlite3RunParser (in app_mem.out)
==23027== by 0x6ADF84: sqlite3Prepare (in app_mem.out)
==23027== by 0x6AE82B: sqlite3LockAndPrepare (in app_mem.out)
I had the same curiosity after using SQLite with Valgrind and came about this bug entry which indicates that in SQLite's case this is a false positive. It would seem that SQLite does indeed use interior-pointers which is causing Valgrind to respond.
"Bug 573688 has new information -- these are all "possible leaks" and false positives because SQLite moves its pointers to heap blocks 8 bytes in from the start of the block. The easiest way to fix is to extend Valgrind to suppress "possible leak" reports specifically; currently you can only suppress all leaks, which would be dangerous as any SQLite leaks would never be caught. (Though I suppose it could be a reasonable step in the meantime.)"