What can be lost in valgrind

Question

I have a lot of possible lost input from valgrind. What does it mean? Since I use sqlite and it is well tested. I do not think this is the right entry. What am I 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

I had the same curiosity after using SQLite with Valgrind and this error entry appeared, which indicates that in the case of SQLite this is a false result. It would seem that SQLite really uses interior pointers that make Valgrind respond.

“Error 573688 contains new information - all these are“ possible leaks ”and false positives because SQLite moves pointers to heaps of blocks with 8 bytes from the beginning of the block. The easiest way to fix this is to expand Valgrind to suppress“ possible leaks ”, now you can only suppress all leaks, which would be dangerous, since any SQLite leaks would never be caught. (Although, I suppose, this could be a sensible step at the same time.) "

Error 639408 - Suppressing sqlite leaks in Valgrind versions

Answer 2

Frequently asked questions included in version 3.6.1 of the Valgrind source clarify a bit:

"possibly lost" means that your program is skipping memory if you do not do unusual things with pointers, which may cause them to point to the middle of the selected block ; See the user manual for some possible reasons. Use --show-possibly-lost = no if you do not want to see these reports.

(5.2 Miscellaneous, Valgrind FAQ)

The Valgrind user guide talks about how it tracks all heap blocks allocated with malloc / new and describes two ways to track memory:

• By storing the "start pointer" at the beginning of the memory block
• Keeping the "interior pointer" at some place in the middle of the block

Three situations in which internal pointers may occur are:

• The pointer may have originally been a start pointer and was moved intentionally (or not intentionally) by the program.
• This may be a random, unwanted value in memory, completely unrelated, just a coincidence.
• It can be a pointer to an array of C ++ objects (which have destructors) assigned by the 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 XY if the interior-pointer is a real pointer - (n)XY: it XY if the interior-pointer is not a real pointer - (_)XY: it XY in either case 

(4.2.7. Memory Leak Detection, Valgrind User Guide)

It turned out that the warning “Probably lost” covers cases 5-8 (for BBB) of the block above.

This means that a chain of one or more pointers to a block is found, but at least one of the pointers is a pointer to the inside. It may just be a random value in memory that occurs to point to a block, and therefore you should not consider it normal unless you know that you have pointers to the internals.

(4.2.7. Memory Leak Detection, Valgrind User Guide)

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

If you provide more information about how you use the api (and under what circumstances a leak occurs), other people can provide a deeper understanding.

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

Answer 3

From Valgrind faq : “possibly lost” means that your program leaks memory if you don't do funny things with pointers. This is sometimes reasonable. Use --show-possibly-lost = no if you do not want to see these reports.