memcheck - What does possible lost means in valgrind -
i have lot of possible lost entry valgrind. mean ? using sqlite , tested. don't think these correct entry. doing wrong ?
16 bytes in 1 blocks possibly lost in loss record 30 of 844 ==23027== @ 0x4a05e1c: malloc (vg_replace_malloc.c:195) ==23027== 0x6525be: sqlite3memmalloc (in app_mem.out) ==23027== 0x63c579: mallocwithalarm (in app_mem.out) ==23027== 0x63c904: sqlite3dbmallocraw (in app_mem.out) ==23027== 0x6886d6: codeoneloopstart (in app_mem.out) ==23027== 0x68a9c8: sqlite3wherebegin (in app_mem.out) ==23027== 0x68cc9e: sqlite3select (in app_mem.out) ==23027== 0x6a8644: yy_reduce (in app_mem.out) ==23027== 0x6aaeac: sqlite3parser (in app_mem.out) ==23027== 0x6ab357: sqlite3runparser (in app_mem.out) ==23027== 0x6adf84: sqlite3prepare (in app_mem.out) ==23027== 0x6ae82b: sqlite3lockandprepare (in app_mem.out)
i had same curiosity after using sqlite valgrind , came bug entry indicates in sqlite's case false positive. seem sqlite indeed use interior-pointers causing valgrind respond.
"bug 573688 has new information -- these "possible leaks" , false positives because sqlite moves pointers heap blocks 8 bytes in start of block. easiest way fix extend valgrind suppress "possible leak" reports specifically; can suppress leaks, dangerous sqlite leaks never caught. (though suppose reasonable step in meantime.)"
Comments
Post a Comment