Re: [Plplot-devel] Janitorial help needed to fix memory leaks in plplot

[<jc...@fe...>]

On Friday 05 July 2002 21:17, Alan W. Irwin wrote:
| I have just looked deeper into the memory leaks for x01c -dev psc
| reported by valgrind with valgrind option --leak-resolution=3Dhigh.  1
| of them was a problem with glibc fopen, 3 of them were problems with
| glibc ctime, 5 of them were problems with glibc dlopen, and the
| remaining 14 (of 23 total under high resolution) all occur in
| plinitDispatchTable.
|
| plinitDispatchTable calls plstrdup at lines 1643, 1644, 1657-1660,
| and 1674. Non of those are freed again,

The problem with plstrdup() is that you don't know when/if you can free=20
the allocated memory; if the duplicated string pointer is stored in a=20
global variable or structure, then you can't know where/when will it be=20
needed again.

| and the 1643 and 1644
| pointers are eventually lost (and those lines are called twice)
| according to valgrind. I am wondering if the lost pointers are due to
| using the same structure for static and dynamic drivers or whether
| there is a misconfiguration of driver number for my particular
| configuration?  (I configured with
| --enable-dyndrivers --enable-gnome --enable-ntk).
|
| plinitDispatchTable also calls malloc at lines 1591, 1601, 1613,
| 1614, and 1640.  None of those are freed.

They could probably be freed when plend() or plend1() are called, this=20
is, when the driver is closed.

=3D=3D26486=3D=3D    definitely lost: 28 bytes in 2 blocks.
=3D=3D26486=3D=3D    possibly lost:   0 bytes in 0 blocks.
=3D=3D26486=3D=3D    still reachable: 6702 bytes in 225 blocks.

I have only used valgrind a few times, but the final report makes me=20
belive that the "still reachable:" line means that those are global=20
variables, and could only be freed at plend/1, which most of the case=20
is not a leak, as most of the time the program finish after that point=20
(but could be fixed anyway). The "definitely lost" line probably means=20
a real leak, as the pointers to the memory are lost.

|  In any case I think some
| checks should go in after the mallocs to be sure the memory was
| allocated successfully.

Sure.

|
| Geoffrey, I am addressing this question to you since
| plinitDispatchTable was originally your code.  I would like to put
| the appropriate frees in plinitDispatchTable for the various plstrdup
| and malloc calls, but I am not sure of the right place to do this
| since I don't follow the code that easily.  Once a device has been
| chosen, is there any need for these memory areas? Please advise!

I'm not looking at the code, but if those addresses are referenced in=20
other places, then you can't free them. Remember also that more than=20
one device can be opened at the same time, e.g., when printing.

Joao

|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Bringing you mounds of caffeinated joy.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel