(get_in_tkt.c line 321). So the code is reading from a freed memory
> block and you need to figure out why the code still believes the memory
> block is valid. Presumably a pointer to it was not cleared when the
> block was freed.
>
> Markus Moeller wrote:
>> I found the do
4 free'd
==9729==at 0x4026BFA: free (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9729==by 0x40E3790: krb5_free_creds (kfree.c:221)
==9729==by 0x80897A8: krb5_create_cache (xxx.c:1160)
==9729==by 0x8050AD8: main (xxx.c:368)
How do I interpret this ?
Thank you
Mark
I also see
Address 0x4595548 is x bytes inside a block of size y free'd
For what do I need to look to fix it (Do I need to fix it ?)
Thank you
Markus
"Markus Moeller" wrote in message news:...
> Hi,
>
> When I run valgrind I get sometimes messages like:
>
>
Hi,
When I run valgrind I get sometimes messages like:
Invalid write of size x
or
Invalid read of size x
in my logfile. What do they mean ? What do I need to do to fix them ?
Thank you
Markus
--
Download Intel® P
Hi,
I have an application which when using
valgrind --log-file=prog.val --leak-check=full --show-reachable=yes -v
./prog shows no memory leak, but when I look at ps or top I see a big memory
usage, but I don't know which part of the program or library is allocating
and freeing the memory. Is
