What does possible lost means in valgrind

Question

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)

Answer 1

The FAQ included with version 3.6.1 of the Valgrind source does elaborate a little more:

"possibly lost" means your program is leaking memory, unless you're doing unusual things with pointers that could cause them to point into the middle of an allocated block; see the user manual for some possible causes. Use --show-possibly-lost=no if you don't want to see these reports.

(5.2. Miscellaneous, Valgrind FAQ)

The Valgrind user manual talks about how it keeps track of all heap blocks allocated with malloc/new and describes two ways you can keep track of memory:

1. By maintaining a "start-pointer" to the start of the memory block
2. By maintaining an "interior-pointer" to some location in the middle of the block

Three situations in which interior-pointers could occur:

1. The pointer might have originally been a start-pointer and have been moved along deliberately (or not deliberately) by the program.
2. It might be a random junk value in memory, entirely unrelated, just a coincidence.
3. It might be a pointer to an array of C++ objects (which possess destructors) allocated with new[].

Possible scenarios:

     Pointer chain            AAA Category    BBB Category
     -------------            ------------    ------------
(5)  RRR ------?-----> BBB                    (y)DR, (n)DL
(6)  RRR ---> AAA -?-> BBB    DR              (y)IR, (n)DL
(7)  RRR -?-> AAA ---> BBB    (y)DR, (n)DL    (y)IR, (n)IL
(8)  RRR -?-> AAA -?-> BBB    (y)DR, (n)DL    (y,y)IR, (n,y)IL, (_,n)DL

Pointer chain legend:
- RRR: a root set node or DR block
- AAA, BBB: heap blocks
- --->: a start-pointer
- -?->: an interior-pointer

Category legend:
- DR: Directly reachable
- IR: Indirectly reachable
- DL: Directly lost
- IL: Indirectly lost
- (y)XY: it's XY if the interior-pointer is a real pointer
- (n)XY: it's XY if the interior-pointer is not a real pointer
- (_)XY: it's XY in either case

(4.2.7. Memory leak detection, Valgrind user manual)

It turns out that the warning "Possibly lost" covers cases 5-8 (for the BBB) block above.

This means that a chain of one or more pointers to the block has been found, but at least one of the pointers is an interior-pointer. This could just be a random value in memory that happens to point into a block, and so you shouldn't consider this ok unless you know you have interior-pointers.

(4.2.7. Memory leak detection, Valgrind user manual)

SO, in a rather long winded way we come to the same conclusion as fbafelipe, that is; assuming you are using the API correctly either sqlite is leaking a little memory or it is engaging in one of the valid cases above. Given the sqlite projects maturity, it is probably safe to assume that the warning isn't much cause for concern.

If you provide more information about how you are using the api (and under what circumstances the leak occurs) other people might be able to provide more insight.

Reference: Valgrind 3.6.1 source, doc/faq.html, doc/mc-manual.html

Answer 2

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.)"

Bug 639408 - Suppress sqlite leaks in Valgrind runs