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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2008, 12:21 UTC
Message-ID: <7vfxwze0te.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <478C1D7A.6090103@nrlssc.navy.mil>

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

Show 7 quoted lines

> Brandon Casey wrote:
>> I got this message from git-commit:
>> 
>> $ git commit -a
>> <edit message, :wq>
>> fatal: Out of memory? mmap failed: Bad file descriptor
>> Create commit <my_prompt_string>

I think from your earlier reports we already know that the issue is that somebody is closing a file descriptor we opened for a packfile and makes the code to shuffle the window that is used to access the packfile unhappy because it uses the fd to mmap.

> I ran git-bisect and the result is below. Doesn't look like
> much help though.

That change alone does look innocuous, but indeed is around the place the code finds that the necessary fd is already closed.

> The other possibly useful info is that running
> 'git commit -a -C HEAD --amend' does not cause the error.

A huge difference between "-C HEAD" and a commit with an editor is that the former bypasses the git-status code to fill the commit message template. In addition to that, the latter spawns a new process.

It could be the editor codepath may be closing the fd when it shouldn't, or some atexit() thing is triggering incorrectly. IIRC the fd incorrectly closed was #6, so it is not likely that process spawning code that may shuffle low fds is the culprit.

As Linus said already (and Alex suggested earlier in the nearby thread), strace output might be a good place to help digging this issue further, instead of us idly speculating.

What platform is this on?

Does it reliably reproduce for any commit in the repository, or reliably reproduce for one particular commit, or sometimes reprooduce for one particular commit?