Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.