Re: Problem with memoryleak in octstr

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-----