On Mon, Oct 03, 2005 at 03:23:50PM +0300, Pavel Tsekov wrote:
> Everyone here is capable to run valgrind on its own.
>
indeed. but hardly anyone does. let alone, covers all paths -
valgrind is a runtime analysis tool, which means that you actually have
to do extensive testing.
> I think the genera
On Thu, 29 Sep 2005, Oswald Buddenhagen wrote:
> On Thu, Sep 29, 2005 at 08:57:22PM +0200, Pavel Tsekov wrote:
> > > Maybe this time I'll properly report memory leaks :)
> >
> > Maybe its about time stop playing valgrind and other tools you do not
> > understa
Pavel Tsekov wrote:
Maybe its about time stop playing valgrind and other tools you do not
understand. In case you want to file a real bug report take your time and
analyse the suspected code properly. Once you are sure that there is a real
bug involved post your analisys to the general mailing li
On Thu, Sep 29, 2005 at 08:57:22PM +0200, Pavel Tsekov wrote:
> > Maybe this time I'll properly report memory leaks :)
>
> Maybe its about time stop playing valgrind and other tools you do not
> understand. In case you want to file a real bug report take your time and
> ana
> Maybe this time I'll properly report memory leaks :)
Maybe its about time stop playing valgrind and other tools you do not
understand. In case you want to file a real bug report take your time and
analyse the suspected code properly. Once you are sure that there is a real
bug involved p
Hello,
Maybe this time I'll properly report memory leaks :)
---1---
==8620== 96 bytes in 8 blocks are definitely lost in loss record 80 of 108
==8620==at 0x1B909222: malloc (vg_replace_malloc.c:130)
==8620==by 0x1B954ADF: g_malloc (in /usr/lib/libglib-2.0.so.0.600.6)
==8620==
