Date: Mon, 16 Jan 2006 15:54:00 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060116135400.GA28974@flame.pc> In-Reply-To: <09F49F8F-A207-4A0C-A1F0-E905E6148055@FreeBSD.org> References: <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <20060112182804.GA1047@flame.pc> <20060113012900.GA16082@flame.pc> <554CC8A8-35FB-424A-B883-505C26ECBBE8@FreeBSD.org> <20060114213238.GA15253@flame.pc> <09F49F8F-A207-4A0C-A1F0-E905E6148055@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-01-15 21:04, Jason Evans <jasone@FreeBSD.org> wrote: > On Jan 14, 2006, at 1:32 PM, Giorgos Keramidas wrote: > >On 2006-01-13 11:07, Jason Evans <jasone@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060116135400.GA28974>