[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c4df15307fbf17bc9e5e625ad41807bb@smtp.hushmail.com>
Date: Wed, 17 Apr 2013 00:14:06 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Segfaults probably caused by DEBUG code in memory.c
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.
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.
