Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor

Brandon Casey [off-list ref] writes:

Junio C Hamano wrote:

quoted

Brandon Casey [off-list ref] writes:

quoted

It's reproduceable for me by amending the commit.

Reliably reproducible?  Can you build with "-O0 -g" and run
"commit --amend" under gdb?

make NO_CURL=1 CFLAGS='-O0 -g'
Done.

I also moved xmmap into commit.c, and turned the inlined definition
in git-compat-util.h into a declaration.


I set a breakpoint on xmmap(). This is the backtrace on the last entry
into xmmap() before it die()'ed.

The fstat message at the end is from a call to fstat that I added to
print out the file size (to compare with mmap length). As you can
see the fstat also fails with the 'Bad file descriptor' message.

#0  xmmap (start=0x0, length=996168, prot=1, flags=2, fd=6, offset=0)
    at commit.c:680
#1  0x080acf30 in use_pack (p=0x8150650, w_cursor=0xffffc0ac, offset=94828, 
    left=0xffffc06c) at sha1_file.c:748

That's the pack window shuffling code in use_pack().  I presume
your additional fstat is inside xmmap(), so if p->pack_fd is
already closed when this xmmap() call is made, that would
explain the symptom.

	while (packed_git_limit < pack_mapped
		&& unuse_one_window(p, p->pack_fd))
		; /* nothing */
	win->base = xmmap(NULL, win->len,
		PROT_READ, MAP_PRIVATE,
		p->pack_fd, win->offset);

I wonder what's the best way to find out who closes file
descriptor #6 without clearing p->pack_fd that still holds #6?
My reading of unuse_one_window() is that it tried to avoid
closing p->pack_fd, so it may already have been closed when we
get to this codepath.

Shawn, does this ring a bell?