GNU bug report logs - #17215
Build failure

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: David Kastrup <dak <at> gnu.org>,  Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17215 <at> debbugs.gnu.org
Subject: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 14:34:55 -0700

[Message part 1 (text/plain, inline)]

On 04/11/2014 01:58 PM, David Kastrup wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
>>>> It would appear that this particular bug yielded to the pure size
>>>> increase.  What a singularly useless error behavior for a problem that
>>>> is expected to reoccur with some regularity!
>>> Still waiting to hear a response to my previous question on why we don't
>>> just abort as soon as we detect pure overflow.
>>
>> Good question.  The reason is largely histerical, where it was
>> convenient to still have a partly usable Emacs.  Nowadays, many more
>> people build their Emacs from trunk without having the technical
>> knowledge to detect and handle this problem, so it's probably better to
>> just abort.
> 
> I fail to see how an Emacs that segfaults during the build can be
> considered usable to a degree making sense.

Emacs didn't always segfault (well, abort, really) on pure overflow ---
I broke it. Before, when we noticed we oveflowed pure space, we would
continue (mallocing more pure space), then just refuse to GC. Ever.

The benefit of this scheme (as opposed to failing early) is that you can
tell *by how much* pure space overflowed, but I don't think that this
power is very useful given that users generally don't know how to find
this information. IMHO (and I think Stefan agrees), we should just abort
as soon as we detect pure space overflow and ask users to increase the
necessary constants in the source.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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