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

quoted text
> 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?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html