Loading ...
Sorry, an error occurred while loading the content.

Re: [ploticus] Re: Memory leak detected with Valgrind

Expand Messages
  • Jeff Mohler
    I wonder if this is realted to the core dumps on my REALLY HUGE files.
    Message 1 of 4 , Feb 20, 2009
    • 0 Attachment
      I wonder if this is realted to the core dumps on my REALLY HUGE files.

      On Thu, Feb 19, 2009 at 7:54 AM, Joel Natividad <joel.natividad@...> wrote:

      Steve,
      Finally pinned down the overflow to fieldnames.c, in the PL_getfname function, line 115:

      else strcpy( result, fname[ n-1 ] );

      Basically, pl abends when header=yes and when the header row has fieldnames longer
      than ~9 characters.

      This was happening with vbars, and I suspect, with the other plot types too. (I tried with
      scatterplot, but I suspect there is another issue there. In the scat.pl prefab, the script
      refers to #usefname when header=yes, but inside proc_scat.c, it refers to #usexname and
      #useyname)

      I triaged it with a band-aid solution by replacing the line with:

      else strncpy( result, fname[ n-1], strlen(result));

      which as you know, is a kludge and will truncate the fieldname.

      Any suggestions? fixes? I tried diving into the code (specifically - getnextattr in execline.c
      - but have not been able to divine how to fix this elegantly)

      Thanks,
      Joel



      --- In ploticus@yahoogroups.com, "Joel Natividad" <joel.natividad@...> wrote:
      >
      > Hi Steve,
      > Been trying to track down an invalid free when using legends and headers with the
      > prefabs:
      >
      > *** glibc detected *** /usr/bin/ploticus: free(): invalid next size (fast): 0x09d2dc90 ***
      >
      > When I strip out the header from the csv file and set header=no, ploticus runs without
      > problems.
      >
      > So I compiled with -g o0, and ran valgrind --leak-check=full --show-reachable=yes pl
      -
      > prefab...
      >
      > Still going through the tests (valgrind is warning about a lot of invalid reads/writes,
      which
      > may be false positives), but I already found a legit leak.
      >
      > In grgd.c, PLGG_setup, there is a malloc that is never freed, even in PL_free.
      >
      > Thought I'd pass it along.
      >
      > Thanks,
      > Joel
      >


    • Joel Natividad
      Jeff, The input file wasn t that big - only about 1kb. Its a moot point anyway. Just got a note from Steve that he confirmed it is a memory management problem
      Message 2 of 4 , Mar 3, 2009
      • 0 Attachment
        Jeff,
        The input file wasn't that big - only about 1kb.

        Its a moot point anyway. Just got a note from Steve that he confirmed it is a memory
        management problem and the fix will be incorporated into the next release of Ploticus.

        In the meantime, you may want to avoid using legends in prefabs.

        Best,
        Joel

        --- In ploticus@yahoogroups.com, Jeff Mohler <speedtoys.racing@...> wrote:
        >
        > I wonder if this is realted to the core dumps on my REALLY HUGE files.
        >
        > On Thu, Feb 19, 2009 at 7:54 AM, Joel Natividad <joel.natividad@...>wrote:
        >
        > > Steve,
        > > Finally pinned down the overflow to fieldnames.c, in the PL_getfname
        > > function, line 115:
        > >
        > > else strcpy( result, fname[ n-1 ] );
        > >
        > > Basically, pl abends when header=yes and when the header row has fieldnames
        > > longer
        > > than ~9 characters.
        > >
        > > This was happening with vbars, and I suspect, with the other plot types
        > > too. (I tried with
        > > scatterplot, but I suspect there is another issue there. In the scat.pl
        > > prefab, the script
        > > refers to #usefname when header=yes, but inside proc_scat.c, it refers to
        > > #usexname and
        > > #useyname)
        > >
        > > I triaged it with a band-aid solution by replacing the line with:
        > >
        > > else strncpy( result, fname[ n-1], strlen(result));
        > >
        > > which as you know, is a kludge and will truncate the fieldname.
        > >
        > > Any suggestions? fixes? I tried diving into the code (specifically -
        > > getnextattr in execline.c
        > > - but have not been able to divine how to fix this elegantly)
        > >
        > > Thanks,
        > > Joel
        > >
        > >
        > > --- In ploticus@yahoogroups.com <ploticus%40yahoogroups.com>, "Joel
        > > Natividad" <joel.natividad@> wrote:
        > > >
        > > > Hi Steve,
        > > > Been trying to track down an invalid free when using legends and headers
        > > with the
        > > > prefabs:
        > > >
        > > > *** glibc detected *** /usr/bin/ploticus: free(): invalid next size
        > > (fast): 0x09d2dc90 ***
        > > >
        > > > When I strip out the header from the csv file and set header=no, ploticus
        > > runs without
        > > > problems.
        > > >
        > > > So I compiled with -g o0, and ran valgrind --leak-check=full
        > > --show-reachable=yes pl
        > > -
        > > > prefab...
        > > >
        > > > Still going through the tests (valgrind is warning about a lot of invalid
        > > reads/writes,
        > > which
        > > > may be false positives), but I already found a legit leak.
        > > >
        > > > In grgd.c, PLGG_setup, there is a malloc that is never freed, even in
        > > PL_free.
        > > >
        > > > Thought I'd pass it along.
        > > >
        > > > Thanks,
        > > > Joel
        > > >
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.