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

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

Expand Messages
  • Jeff Mohler
    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
      >


    • Show all 4 messages in this topic