Web lists-archives.com

Re: fatal: Out of memory, getdelim failed under NFS mounts

Thank you Junio

On Thu, 10 Aug 2017, Junio C Hamano wrote:
> There is only one getdelim() call, which was introduced in v2.5.0
> timeframe, and it is used like this:

> 	r = getdelim(&sb->buf, &sb->alloc, term, fp);

> 	if (r > 0) {
> 		sb->len = r;
> 		return 0;
> 	}
> 	assert(r == -1);

> 	/*
> 	 * Normally we would have called xrealloc, which will try to free
> 	 * memory and recover. But we have no way to tell getdelim() to do so.
> 	 * Worse, we cannot try to recover ENOMEM ourselves, because we have
> 	 * no idea how many bytes were read by getdelim.
> 	 *
> 	 * Dying here is reasonable. It mirrors what xrealloc would do on
> 	 * catastrophic memory failure. We skip the opportunity to free pack
> 	 * memory and retry, but that's unlikely to help for a malloc small
> 	 * enough to hold a single line of input, anyway.
> 	 */
> 	if (errno == ENOMEM)
> 		die("Out of memory, getdelim failed");

> So the function is returning -1 and leaving ENOMEM in errno on
> Yaroslav's system.  

> I wonder if we are truly hitting out of memory, though.  The same
> symptom could bee seen if getdelim() does not touch errno when it
> returns -1, but some other system call earlier set it to ENOMEM,
> for example.

> If the same version of Git is recompiled there without HAVE_GETDELIM
> defined, would it still die with out of memory (presumably inside
> the call to strbuf_grow() in the strbuf_getwholeline() function)?

will check now...  for my own education (rotten by Python) -- how
do you know which syscall set errno to be analyzed at this specific
point?  may be it was already set to ENOMEM before entry to this

Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik