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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2008, 01:08 UTC
Message-ID: <7vtzljzw8n.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <47880D18.8030405@nrlssc.navy.mil>

Brandon Casey <casey@nrlssc.navy.mil> writes:

Show 27 quoted lines

> Junio C Hamano wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> 
>>> 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?