[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20130609174021.WWR58.569403.imail@eastrmwml206>
Date: Sun, 9 Jun 2013 17:40:21 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Confusing output from memdbg
There is a check within the self test code. It grabs memory state prior to running the format, and then compares it to the state after the format has completed.
So for first format, memory state is grabbed, and clear. The format runs. Then when things are 'shut down', the memory state is checked, and is NOT the same. This generates a message.
The next format is prepared to run. memory state is saved. The format runs. Now, that prior memory block is freed, and a new one allocated. The format runs, cleans up, etc. Then memory is checked. It is not the same, there is a later allocated block, and thus, it is reported.
This is what is happening (I am 95% sure).
I will have to come up with some way to not trigger warnings in this case. Similar to all the pedantic warnings we have during compiling. 95% of them are simply busy work, trying to re-arrange things to pacify the compiler. This error message is somewhat the same thing. We really are not leaking memory. Well, the last alloc is left unfreed, but nothing is 'leaked'. However, there is no way at this time, that the automatic memory checking code would 'know' that we are doing things correctly here. But I will come up with some way.
Jim.
---- magnum <john.magnum@...hmail.com> wrote:
> 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.
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.
