[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mem leak in



Harry,

THis got lost for a few days... It's now in the bug db and I hope to look into it this afternoon.

James
On May 5, 2005, at 3:41 PM, Harry Mangalam wrote:

Sorry for all the bad news lately, but in responding to a query from an nco user, we've also found a big mem leak in the DODS client lib. Attached is the output from a valgrind memcheck of the ncrcat accessing the files via DODS. Using the files /locally/ shows no mem leaks. The guilty code appears
to be here:

(extract of attached message)
==19478== 8129824 bytes in 73 blocks are definitely lost in loss record 140 of
141
==19478== at 0x1B906985: operator new[](unsigned) (vg_replace_malloc.c:138)
==19478==    by 0x1B9DE4AC: Vector::buf2val(void**) (Vector.cc:711)
==19478== by 0x1B979DCA: DODvario(int, int, unsigned const*, unsigned
const*, int const*, void*, int) (Dputget.cc:428)
==19478==    by 0x1B97E51B: nc_get_vara_double (Dputget.cc:1907)
==19478==    by 0x1B954B41: nco_get_vara (nco_netcdf.c:664)
==19478==    by 0x1B965208: nco_var_val_cpy (nco_var_utl.c:1015)
==19478==    by 0x804A436: main (ncra.c:460)
==19478==
==19478==
==19478== 94633984 bytes in 40 blocks are possibly lost in loss record 141 of
141
==19478== at 0x1B906985: operator new[](unsigned) (vg_replace_malloc.c:138)
==19478==    by 0x1B9DE4AC: Vector::buf2val(void**) (Vector.cc:711)
==19478== by 0x1B979DCA: DODvario(int, int, unsigned const*, unsigned
const*, int const*, void*, int) (Dputget.cc:428)
==19478==    by 0x1B97E43B: nc_get_vara_float (Dputget.cc:1890)
==19478==    by 0x1B954BDC: nco_get_vara (nco_netcdf.c:663)
==19478==    by 0x1B964676: nco_var_get (nco_var_utl.c:613)
==19478==    by 0x804A630: main (ncra.c:518)

I say 'appears to be' b/c I had to kill the job and so the process terminated abnormally, but valgrind is pretty good about detecting mem gone astray. If you need a complete run, I can re-run with smaller input, but you probably
have better tools there.


Charlie's response to the initial query describing the problem is here:
https://sourceforge.net/forum/message.php?msg_id=3135195

I verified the problem on 2 other Intel PIII platforms and one dual Opteron (64bit mode), all running variants of Debian unstable, all with gcc/g++ 3.4.4

Harry
<valgrind.ncrcat.output.bz2>
--
James Gallagher                jgallagher at opendap.org
OPeNDAP, Inc                   406.723.8663