GNU bug report logs - #11519
"Wrong type argument: characterp" building custom-deps while boostrapping

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: handa <at> gnu.org, schwab <at> linux-m68k.org, rms <at> gnu.org, 11519 <at> debbugs.gnu.org, lekktu <at> gmail.com
Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping
Date: Sun, 27 May 2012 22:15:00 -0400

> I didn't mean STRING_CHAR_*.  I agree that they should be fixed not to
> have such unexpected side effect.  They should be read-only operations.
> As a temporary band-aid for Emacs 24.1, I suggest the change below.

Looks fine (should make the regex.c patch unnecessary).

> You said "malloc", so I took an issue with the MS C runtime
> implementation of malloc.  Since all the other implementations suffer
> from fragmentation, there's no reason to believe that the MS
> implementation avoids that danger.

The problem is inherent to the malloc API, pretty much, yes.

> We could easily turn off buffer relocation in ralloc.c for good, by
> fixing the value of use_relocatable_buffers at zero.  But I'm worried
> that this would cause Emacs on Windows run out of memory (or act as if
> it were) faster.

AFAIK, Emacs under GNU/Linux and Mac OS X uses non-relocatable buffers,
and they don't seem to suffer more from fragmentation problems than
Emacs under Windows.  But yes, unless we use an mmap-style allocation,
it would use more actual memory.

> For example, in an Emacs session that runs for 2
> weeks and has a 200MB working set, I just visited a 1.3GB file, went
> to its middle and typed "C-u 30000 d" to insert 30K characters.  Emacs

For sure editing such large file in a 32bit address space might prove
problematic without relocation, (and even with buffer relocation, some
non-buffer allocation might end up fragmenting the address space too
much) but luckily few people do that (you need to compile
with --wide-int to be able to do that).

> Yet another alternative is to emulate mmap on Windows using the
> equivalent Windows API.  But that requires a research comparing mmap
> features we need and use on Posix platforms with the features offered
> by Windows, to make sure this is at all feasible.

That would be nice.

> Such a research
> would need to be done by someone who knows enough about mmap and is
> willing to do the job.  Do we have such a person on board?

I don't volunteer.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.