Re: mmap failure in master 1aa69c73577df21f5e37e47cc40cf44fc049121e

[Jeff King <peff@peff.net>]

On Sun, May 31, 2020 at 12:46:30PM +0200, Jan Christoph Uhde wrote:

> lstat("gcc/testsuite/gdc.test/fail_compilation/b3841.d", {st_mode=S_IFREG|0644, st_size=2643, ...}) = 0
> openat(AT_FDCWD, "gcc/testsuite/gdc.test/fail_compilation/b3841.d", O_RDONLY) = 3
> mmap(NULL, 2643, PROT_READ, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot allocate memory)
> openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> write(2, "fatal: mmap failed: Cannot alloc"..., 43fatal: mmap failed: Cannot allocate memory
> ) = 43

So we open a file in the working tree, and that mmap fails. I guess this
is probably the call to xmmap() in diff_populate_filespec(). That file
isn't particularly large.

Is it possible that your local repository has large number of packs? Git
will leave open maps to each pack's index file, plus some packs
themselves (ones we're accessing, plus we map+close small ones), plus
whatever maps are used by libc to malloc.  The kernel default limit for
the number of maps is 65530. If you have on the order of 30,000 packs
you might run into this limit.

You can check the number of packs with "git count-objects -v", and the
map limit with "sysctl vm.max_map_count".

If that's the problem, the solution is to repack (which should also
generally improve performance). If you have trouble repacking due to the
limits, you can overcome the chicken and egg with:

  sysctl -w vm.max_map_count=131060

-Peff