Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Jun 2013 17:20:12 -0400
From:  <>
Subject: Re: Confusing output from memdbg

It is not a 'leak', but it is a 'left over' memory alloc that is not cleaned.   What is happening is we first free any prior alloc, then alloc.  However, we always have at least one alloc.

If we want this warning to go away, we need to have some 'final' code that does a free of the allocated memory.  I will have a look at what we have.  Is there anything that closes down the kernel?  If so, then after everything is close down, simply do a MEM_FREE.  That will free any allocated block, and null the pointer, AND there should be no straggler memory.


---- magnum <> wrote: 
> Jim,
> I tried turning memdbg on and run --test=0
> For CPU and CUDA formats, all is fine. But for OpenCL I get this output for all but the first format: "Mem leak: nnnn bytes, alloc_num nn, file common-opencl.c, line 1267"
> This is the corresponding code:
>   1266          MEM_FREE(kernel_source);
>   1267          kernel_source = mem_calloc(source_size + 1);
> How can that be a memory leak? I put some printf's in to verify that before line 1266, the old pointer is intact so that buffer is freed in line 1266. I also verified the pointer is reset to NULL after line 1266. So why does it think it's a memory leak?
> magnum

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.