[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1589da25c6bcf1aabec2219a855717a5@smtp.hushmail.com>
Date: Sun, 9 Jun 2013 23:29:38 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Confusing output from memdbg
No, what you talk about is already in place. I'm saying this warning is printed for *every* format but the first one, during a "-t=0 -form=opencl" run. So what happens is
1. First format, pointer is NULL, line 1266 is a no-op
2. pointer gets an alloced block in line 1267
3. Second format, old block is supposedly freed in line 1266 and pointer becomes NULL
4. pointer gets a new alloced block in line 1267. Here, the warning is printed.
Repeat step 3 & 4 for every format. Then,
5. At end of run, clean_opencl_environment() is called which does the final free you mention. But even here, it doesn't seem to actually get freed because memdbg complains about it at exit.
So for some reason (this on OSX) memdbg does not work like it should, but the pointer becomes NULL. I'll try and see if I get the same behaviour on Bull.
magnum
On 9 Jun, 2013, at 23:20 , jfoug@....net wrote:
> 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.
