Brandon Casey <casey@xxxxxxxxxxxxxxx> writes: > Junio C Hamano wrote: >> Brandon Casey <casey@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html