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

[Alan W. I. <ir...@be...>]

On Mon, 8 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> 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
> the allocated memory; if the duplicated string pointer is stored in a
> global variable or structure, then you can't know where/when will it be
> needed again.

I agree you could not do it from plstrdup itself.  As that function makes
clear it is the responsibility of the caller to free the memory again, but
the current code does not do that.

>
> | 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
> 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
> belive that the "still reachable:" line means that those are global
> variables, and could only be freed at plend/1, which most of the case
> is not a leak, as most of the time the program finish after that point
> (but could be fixed anyway). The "definitely lost" line probably means
> a real leak, as the pointers to the memory are lost.

I don't wish to be too fanatical about the "still reachable" ones, although
I think we should free stuff explicitly if it is straightforward to do so
simply to clarify our code. Geoffrey, is is straightforward?

The lost ones are a more urgent problem.  Geoffrey, do you expect those
particular pointers to be lost or is this some evidence of a bug (or
misconfiguration, say, if we have overlapping device numbers)?

I have now done some much more extensive valgrind checks.

I have done all our usual testing examples (excluding 14, 17, 19, and 20)
for psc and png using the C front end and also png for the python front end=
=2E
I did encounter one memory mismanagement problem (attempted memory access
from uninitialized static area or outside a dynamically allocated area)
which I fixed so plplot is now valgrind clean in this respect.

I also did the leak check (as opposed to memory mismanagement check) for a
complete python run of all examples using png.  No new plplot free memory
problems surfaced beyond the ones I have already indicated for
plInitDispatchTable. So once we get rid of those, plplot will be completely
valgrind clean (at least for the examples/device combinations I have tried)=
=2E

Alan