[Bug 747554] New: suppressions: silence possible valgrind false positive

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=747554

            Bug ID: 747554
           Summary: suppressions: silence possible valgrind false positive
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: vincent.penquerch at collabora.co.uk
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Running: make -C tests/check elements/deinterlace.valgrind

I see a few of those:

==4552== Invalid read of size 8
==4552==    at 0x5E010EF: __GI___strncasecmp_l (strcmp.S:1897)
==4552==    by 0x5DB23EF: ____strtod_l_internal (strtod_l.c:574)
==4552==    by 0x536B0A0: gst_value_deserialize_double (gstvalue.c:2737)
==4552==    by 0x534E5DF: gst_structure_parse_value (gststructure.c:2312)
==4552==    by 0x535178B: priv_gst_structure_parse_fields (gststructure.c:2229)
==4552==    by 0x5303414: gst_caps_from_string (gstcaps.c:2306)
==4552==    by 0x40252F: deinterlace_check_passthrough (deinterlace.c:237)
==4552==    by 0x402B5D: test_mode_disabled_passthrough (deinterlace.c:414)
==4552==    by 0x50B8A79: srunner_run (check_run.c:450)
==4552==    by 0x50B14BC: gst_check_run_suite (gstcheck.c:824)
==4552==    by 0x40185D: main (deinterlace.c:463)

After a while debugging, I came to the conclusion that either libc is buggy, or
valgrind is, because I can repro the issue with:

#include <stdlib.h>
#include <string.h>
int main(void) {
  char *e=NULL;
  char *p=strdup("interleaved");
  double x=strtod(p,&e);
  free(p);
  return 0;
}

And then I found this:
http://stackoverflow.com/questions/10572715/valgrind-invalid-read-with-c-str-and-strtod

The sample code above seems bugfree.

A nice side effect is that I found in the strtod man page:

       An infinity is either "INF" or "INFINITY", disregarding case.

       A NAN is "NAN" (disregarding case) optionally followed by '(', a
       sequence of characters, followed by ')'.  The character string speci‐
       fies in an implementation-dependent way the type of NAN.

Anyway, I'm proposing this patch which sweeps it under the carpet, but I'll
wait for comments about it, in case I've missed a stupid thing, since blaming
valgrind or libc seems like the easy way out.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.