Date: Tue, 16 Apr 2013 21:32:15 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Segfaults probably caused by DEBUG code in memory.c (was: Segfault for linux-x86-native with -DDEBUG added) Not the same thing. In the normal non-debug code we obviously must do it, because we are re-using one large memory block for many smaller blocks. That is one of mem_alloc_tiny's two reasons to exist. I attribute Frank's segfaults to a bug in his malloc() but the fix should definitely be there anyway (we might want MEM_ALIGN_CACHE or something else, for other reasons than strict requirements) and it should have been there in the first place. magnum On 16 Apr, 2013, at 20:49 , "jfoug" <jfoug@....net> wrote: > I read the man pages myself, prior to posting that email. I had started on > the email, then read the dox. I almost stopped, to allow others to find the > 'real' problem. But I then spotted the bottom of the mem_alloc_tiny > function (where a huge block is allocated and used). Since it had the > alignment 'fix' there, I figured that no matter what the dox list, this is > something that REALLY must happen, to assure proper alignment. I had not > tested the code I posted in the email, I am not where I can do so right now. > However, it really looked like that code was added to the bottom of the > function on purpose, so likely it is really a requirement, and the dox are > misleading, or worse, simply wrong. > > From: magnum [mailto:john.magnum@...hmail.com] >> >> I can't recall now but to my defense, I may have been misled by the man > page. The OSX one explicitly says "The >allocated memory is aligned such > that it can be used for any data type, including AltiVec- and SSE-related >> types". The Linux one states "...suitably aligned for any kind of variable" > which apparently is not really true. > >
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.