639408 - Suppress sqlite leaks in Valgrind runs

Status: RESOLVED FIXED

(Core :: SQLite and Embedded Database Bindings, defect)

Description

[Phil Ringnalda (:philor)]

Bug 573688 on fixing them, this on suppressing them in the meantime so we can make it visible again. Just needs V running on the tryserver, so I can see what I'm doing.

Comment 1

[Nicholas Nethercote [inactive]]

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

Comment 2

[Phil Ringnalda (:philor)]

Wouldn't want to stand in the way of someone who will do the suppressing without benefit of tryserver.

Comment 3

[Phil Ringnalda (:philor)]

Attachment: Suppress 'em

In rather the Alice in Wonderland trial sense of suppressing, but there you are.

Comment 4

[Nicholas Nethercote [inactive]]

Comment on attachment 541990 [details] [diff] [review]
Suppress 'em

Review of attachment 541990 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the below nit fixed.

::: build/valgrind/i686-redhat-linux-gnu.sup
@@ +30,5 @@
>  }
> +{
> +   malloc-libmozsqlite3.so
> +   Memcheck:Leak
> +   fun:malloc

The generated suppressions presumably had a "fun:sqlite3MemMalloc" line after the "fun:malloc" line.  It'd be good to include that here, it makes it a tiny bit more specific, which means it won't suppress any malloc() calls in SQLite that don't go through sqlite3MemMalloc (if indeed there are any).

Comment 5

[Phil Ringnalda (:philor)]

While my vague memory tells me that at one time they might have, they do not. The single most detailed one I found was

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libmozsqlite3.so
   fun:sqlite3_exec
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libxul.so
   obj:/builds/slave/valgrind-linux/objdir/dist/firefox/libxul.so
}

which I suppose means we changed something about how we build sqlite and V no longer understands it at all and suppressing anything now has to wait for someone who actually understands this crap to figure out what changed :(

Comment 6

[Nicholas Nethercote [inactive]]

In that case, your suppression is fine. :)

Comment 7

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/755257708fa3