cvs commit: src/lib/libc/stdlib malloc.c

[Giorgos Keramidas]

On 2006-01-15 21:04, Jason Evans <jasone at FreeBSD.org> wrote:
> On Jan 14, 2006, at 1:32 PM, Giorgos Keramidas wrote:
> >On 2006-01-13 11:07, Jason Evans <jasone at FreeBSD.org> wrote:
> >>On Jan 12, 2006, at 5:29 PM, Giorgos Keramidas wrote:
> >>>
> >>>[...]
> >>>
> >>>Does this look like an off-by-one error to you too Jason?
> >>>Apparently, the allocated size of s->data is s->size, which is 873
> >>>bytes, but then Emacs tries to access s->data[873].
> >>>
> >>>Does it look like I'm right in thinking that this is a bug in Emacs?
> >>
> >>This looks like a bug in emacs, as you say, but I don't know if it
> >>has any particular relation to the posix_memalign() changes.
> >
> >Apparently it does seem related to posix_memalign() changes.
> >When I bootstrap Emacs without posix_memalign(), by manually
> >tweaking src/config.h after configure runs, and #undef
> >POSIX_MEMALIGN, then it passes the bootstrap stage normally.
>
> I looked into this some, and it appears that it is a configuration
> problem in emacs.  When I ran 'configure', both GNU_MALLOC and
> HAVE_POSIX_MEMALIGN were defined in config.h.  This appears to be a
> recipe for disaster, since the allocator included with emacs does not
> provide posix_memalign().  This probably means that emacs is calling
> into both its own allocator and libc's, then trying to free memory
> that was allocated by libc, using its own allocator.
>
> Additionally, I see dlmalloc-specific code that tells dlmalloc not to
> mmap() during allocation, since emacs's undump procedure doesn't
> preserve mmap'ed regions.
>
> It looks like emacs is by default configured to use emacs's
> allocator, which is good (getting emacs to work with FreeBSD's malloc
> probably isn't worth the trouble).  However, the emacs code makes the
> mistake of deciding whether to use posix_memalign() based on
> HAVE_POSIX_MEMALIGN, rather than something like USE_MEMALIGN -- emacs
> is mixing and matching allocators and their features, which is not
> good.  I'm not familiar enough with emacs's configuration system to
> know the correct way of fixing this, but one way or another, emacs
> needs to not use posix_memalign().

Jason, thanks for the time you spent into this :)

If disabling posix_memalign() fixes the problems of Emacs's use of
allocators, I'll probably submit a patch to emacs-devel to do exactly
this.  It's one of the things RMS himself wouldn't object to, as he
has stated already, so I think it's fine for the time being.