bug#8884: closed (Re: bug#8884: wide-int crash)

[Peter Dyballa]

Am 18.10.2011 um 17:45 schrieb Andreas Schwab:

> "a bit less than 4 GB" is an exaggeration, "almost 2GB" is much closer
> to the truth.

With Mac OS X 10.5.8 and a PowerPC 7447A CPU GNU Emacs 24.0.90 launched with -Q 
can open (tar) files up to 2,047 MB. Ls reports that 2,147,450,880 is OK and 
2,148,024,320 is too much (2,048 MB). 2**31 is 2,147,483,648.

The TAR file was created by an i386 tar (GNU tar) 1.26 on an external FireWire 
disk I attached either on my fast 64-bit intel based Mac or on my slow 32-bit 
G4, where I performed the tests. In dired-mode I opened the directory and read 
the file in with v. The MB numbers where reported by GNU Emacs' routine which 
asked me to confirm that I really wanted to open such a large file.

While I opened too small files I killed the tar-mode buffer, ejected the disk, 
created a larger file, attached the disk again, and opened from freshened dired 
listing (in my PATH only a gls exists which accepts --dired) the tar file with 
v. This produced failures like these:

        emacs(84226) malloc: *** mmap(size=2113650688) failed (error code=12)
        *** error: can't allocate region
        *** set a breakpoint in malloc_error_break to debug
        
        emacs(84357) malloc: *** mmap(size=2126585856) failed (error code=12)
        *** error: can't allocate region
        *** set a breakpoint in malloc_error_break to debug
        
        emacs(84410) malloc: *** mmap(size=2128408576) failed (error code=12)
        *** error: can't allocate region
        *** set a breakpoint in malloc_error_break to debug
        
        emacs(84517) malloc: *** mmap(size=2136588288) failed (error code=12)
        *** error: can't allocate region
        *** set a breakpoint in malloc_error_break to debug
        
        emacs(84576) malloc: *** mmap(size=2140327936) failed (error code=12)
        *** error: can't allocate region
        *** set a breakpoint in malloc_error_break to debug

Is this expected behaviour? I would have thought GNU Emacs could clear all for 
the file allocated memory... There were still 8 or 9 GB disk space available 
for swap/vm to grow, so this could not have caused the failures. (I killed GNU 
Emacs and launched a new one for each new test.) Or should I send a new bug 
report?

(I can, some rather rainy time, repeat the tests on Mac OS X 10.4.11...)

--
Greetings

  Pete

Work is the curse of the drinking class.
                                – Oscar Wilde