I just tried 3.50 and still the same bug occured. :(
On Mon, Aug 24, 2009 at 10:33 PM, Julian Seward wrote:
> On Monday 24 August 2009 10:22:27 am Ken wrote:
>> I used callgrind to profile a storage engine of mysql and got this out put.
>
>> Callgrind: threads.c:247 (vgCallgrind_post_signal): Ass
On Tue, Aug 25, 2009 at 8:17 AM, Markus Moeller wrote:
>
> 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 prog
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
On Monday 24 August 2009 10:22:27 am Ken wrote:
> I used callgrind to profile a storage engine of mysql and got this out put.
> Callgrind: threads.c:247 (vgCallgrind_post_signal): Assertion 'tid ==
> vgCallgrind_current_tid' failed.
I think that's been fixed in 3.5.0 (not 100% sure though). Upgr
I used callgrind to profile a storage engine of mysql and got this out put.
-
==2402== Callgrind, a call-graph generating cache profiler.
==24
