[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP864F586FC2C99131A1DFC9FDCD0@phx.gbl>
Date: Wed, 17 Apr 2013 00:23:19 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Segfaults probably caused by DEBUG code in memory.c
On 04/17/2013 12:14 AM, magnum wrote:
> On 16 Apr, 2013, at 23:37 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> On 04/16/2013 09:56 PM, jfoug wrote:
>>> In hindsight, in debug mode, you might have gotten the same results by doing
>>> this:
>>>
>>> #if DEBUG
>>> #undef MEM_ALLOC_SIZE
>>> #define MEM_ALLOC_SIZE 0
>>> #endif
>>
>> I really like this solution, because it leaves mem_alloc_tiny (which is
>> complex enough as it is) unchanged.
>>
>> May be even better is to do this in memory.h directly:
>>
>> #if DEBUG
>> /* turn mem_alloc_tiny() into a normal alloc,
>> * to better track problems.
>> */
>> #define MEM_ALLOC_SIZE 0
>> #else
>> #define MEM_ALLOC_SIZE 0x10000
>
> I bought your arguments and did this, even commited it without testing (silly me). But it segfaults for me in unstable, and hangs in bleeding, both in dynamic_1.
>
> I reverted it. You can try for yourself, unstable is 3b53da3 and bleeding is 83a9e10.
My fault:
dynamic_fmt.c:1800: pSaltDataBuf = pNextSaltDataBuf =
mem_alloc_tiny(MEM_ALLOC_SIZE*6, MEM_ALIGN_NON
dynamic_fmt.c:1801: nSaltDataBuf = MEM_ALLOC_SIZE*6;
I should have checked the usage of MEM_ALLOC_SIZE before suggesting the
change.
Frank
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.
