[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130609172012.JT807.570199.imail@eastrmwml207>
Date: Sun, 9 Jun 2013 17:20:12 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
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.
Jim.
---- magnum <john.magnum@...hmail.com> 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.
