Ken A. Redergård wrote:
Hi,
I'm trying to figure out why the following octstr function leak 1 byte of memory for each iteration:
/* test_octstr.c */
#include <unistd.h> #include "gwlib/gwlib.h"
int main(void) { Octstr *os; int i;
gwlib_init();
for (i = 0; i < 100; i++) { os = octstr_format("sadfasdfasdfas"); octstr_append(os, octstr_imm("asdfasdfasdfasdf")); octstr_destroy(os); gwthread_sleep(1); }
gwlib_shutdown();
return 0; }
Watching this with "ps -C test_octstr -F" shows that for every four seconds it leaks 4 bytes... Is the use of octstr incorrect or is it a problem in gwlib ?
hmm, I tried this with valgrind and get the following:
$ valgrind --tool=memcheck --leak-check=yes ./test/test_octstr
==9563== Memcheck, a memory error detector for x86-linux.
==9563== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==9563== Using valgrind-2.1.2, a program supervision framework for x86-linux.
==9563== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==9563== For more details, rerun with: -v
==9563==
==9563== warning: Valgrind's pthread_cond_destroy is incomplete
==9563== (it doesn't check if the cond is waited on)
==9563== your program may misbehave as a result
==9563== warning: Valgrind's pthread_cond_destroy is incomplete
==9563== (it doesn't check if the cond is waited on)
==9563== your program may misbehave as a result
==9563== warning: Valgrind's pthread_cond_destroy is incomplete
==9563== (it doesn't check if the cond is waited on)
==9563== your program may misbehave as a result
2004-08-26 18:01:21 [9563] [0] DEBUG: Immutable octet strings: 1.
==9563==
==9563== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 2)
==9563== malloc/free: in use at exit: 1200 bytes in 29 blocks.
==9563== malloc/free: 11184 allocs, 11155 frees, 717508 bytes allocated.
==9563== For counts of detected errors, rerun with: -v
==9563== searching for pointers to 29 not-freed blocks.
==9563== checked 5445108 bytes.
==9563==
==9563== LEAK SUMMARY:
==9563== definitely lost: 0 bytes in 0 blocks.
==9563== possibly lost: 0 bytes in 0 blocks.
==9563== still reachable: 1000 bytes in 28 blocks.
==9563== suppressed: 200 bytes in 1 blocks.
==9563== Reachable blocks (those to which a pointer was found) are not shown.
==9563== To see them, rerun with: --show-reachable=yes
So valgrind seems _not_ to see any leaking.
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.2 (Cygwin)
mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -----END PGP PUBLIC KEY BLOCK-----
