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

[Brandon Casey <drafnel@gmail.com>]

On Tue, 15 Jan 2008, Junio C Hamano wrote:

>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> While I think the ones that are immediately followed by
>> commit_locked_index() can drop the close(fd) safely, I am not
>> sure about Kristian's changes to the other ones that we
>> currently close(fd) but do not commit nor rollback immediately.
>> These indices are now shown to the hook with open fd to it if
>> you choose not to close them.  Is that okay for Windows guys?  I
>> somehow had an impression that the other process may have
>> trouble accessing a file that is still open elsewhere for
>> writing.
>>
>> So I think the approach along the lines of your "hack" to close
>> and tell lockfile API not to double-close is more appropriate.
>> We would perhaps want "close_lock_file(struct lock_file *)" that
>> calls close(lk->fd) and does lk->fd = -1 without rename/unlink,
>> and replace these close() with that.
>>
>> I am sick today, feeling feverish, and not thinking straight,
>> so I may be talking total nonsense...

> I'll aplly and push out Kristian's one that apparently got
> Tested-by from Brandon for tonight.

I've got a followup patch coming that will remove the rest of
the redundant close()'s and I'll look into your suggestion for
close_lock_file() above.

Currently everything passes the test suite, I just need to do
some manual testing.

-brandon