From: Alex Riesen <raa.lkml@xxxxxxxxx>
Date: Fri, 14 Dec 2007 22:45:33 +0100
> David Miller, Fri, Dec 14, 2007 20:17:36 +0100:
> > ++ git show-ref -q refs/remotes/local/master
> > ++ git branch my3 local/master
> > fatal: Out of memory, malloc failed
>
> Something unusual about the system? Like a malloc debugger in
> LD_PRELOAD configuration?
No, I'm not doing anything fancy like that.
> Maybe you could retry with a little bit instrumentation?
> (The program last failed (git-branch) is normally very benign...)
>
> Something like this:
Here is the output from the debugging patch:
++ git branch my3 local/master
fatal: Out of memory, malloc(4293963242) at git-compat-util.h:256 failed
This bogus size value in hex is 0xfff0adea, FWIW.
I added similar diags to xmemdupz() and xstrndup() and that gives us:
fatal: Out of memory, xstrndup(0x103ebf:4293902657:4293902657) at remote.c:112 failed
(the first three values are xstrndup() vars 'str', 'len', and
the computed second argument to xmemdupz).
That bogus length is being generated via the length argument
passed to make_branch() by handle_config() in remote.c:
if (!prefixcmp(key, "branch.")) {
name = key + 7;
subkey = strrchr(name, '.');
branch = make_branch(name, subkey - name);
What if 'subkey' is NULL? I bet that's what happening here.
I added a debugging check for this and indeed, subkey is NULL
in handle_condig() and that's why 'subkey - name' generates that
bogus negative length.
The string 'key' is "branch.autosetupmerge" in this case.
-
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
