bug#17846: Increase PURESIZE

bug#17846: Increase PURESIZE

[Davor Rotim]

[-- Attachment #1: Type: multipart/alternative, Size: 142 bytes --]

bug#17846: Increase PURESIZE

[Glenn Morris]

Davor Rotim wrote:

> In the current emacs-24 branch value of PURESIZE is too small to build
> Emacs successfully on 32 bit. This issue is already fixed in trunk.

Please provide actual details.
What platform are you on, how big is the overflow?

bug#17846:

[Davor Rotim]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

emacs:0:Pure Lisp storage overflow (approx. 1701883 bytes needed)

This is on GNU/Linux 32-bit (Arch Linux, 3.15.1-1-ARCH i686), gcc 4.9.0
20140604. Sorry for the lack of details in the initial report.

[-- Attachment #2: Type: text/html, Size: 245 bytes --]

bug#17846:

[Glenn Morris]

Davor Rotim wrote:

> emacs:0:Pure Lisp storage overflow (approx. 1701883 bytes needed)

That ties in with what I saw on 32-bit RHEL 6 (I don't normally use
32-bit any more), so I bumped BASE_PURESIZE to 1702000.

I'm worried that this was only now reported...

See also http://debbugs.gnu.org/17255

Perhaps a larger increment should be added, for safety?

bug#17846:

[Davor Rotim]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

I built Emacs with the value of 1800000 (matching the trunk value)
yesterday and had no issues. Currently building with your changes.

[-- Attachment #2: Type: text/html, Size: 159 bytes --]

bug#17846:

[Davor Rotim]

[-- Attachment #1: Type: text/plain, Size: 93 bytes --]

Emacs with BASE_PURESIZE 1702000 builds and runs without problems. This
issue can be closed.

[-- Attachment #2: Type: text/html, Size: 118 bytes --]

bug#17846:

[Stefan Monnier]

>> emacs:0:Pure Lisp storage overflow (approx. 1701883 bytes needed)
> That ties in with what I saw on 32-bit RHEL 6 (I don't normally use
> 32-bit any more),

I use 32bit pretty much everywhere, so this part of the normal testing
is somewhat covered.

> so I bumped BASE_PURESIZE to 1702000.

We definitely need more margin since purespace contains elements
whose size depends on things like the length of the name of the
target-directory.

> Perhaps a larger increment should be added, for safety?

I think we can afford a 1% margin.


        Stefan

bug#17846:

[Glenn Morris]

Stefan Monnier wrote:

> I think we can afford a 1% margin.

OK; further bumped to 1720000.