On Thu, 22 Mar 2007, Linus Torvalds wrote:
>
> Yeehaa! I think I'm on the right trail.
.. and the reason only Alexander sees it, and nobody else does, is that
this one is a bug in the CR/LF creation.
Junio: I think it's your git-apply commit 67160271.
In "try_create_file()", we do:
...
if (convert_to_working_tree(path, &nbuf, &nsize)) {
free((char *) buf);
buf = nbuf;
size = nsize;
}
...
but the thing is, the *caller* still uses the old "buf/nsize", so when you
free it, the caller will now use the free'd data structure, and if it gets
re-used by - for example - the zlib deflate() buffers, you'll get a
corrupt object (if it gets re-used *before*, you'll get the *wrong*
object!). Exactly Alexander's patterns.
Alexander - sorry for all the trouble, this was definitely our bad.
I think the easy temporary fix is to just remove that "free()" and leak a
bit of memory. That gets it through that test with efence for me.
Does that fix it for you, Alexander?
I can't really say whether there are other problems too - electric fence
has a few bugs in that it considers zero-length allocations to be
"probably a bug" and aborts. This makes some of the tests fail with
efence, when re_compile_internal wants to allocate a zero-length object.
(It also writes crap to stderr, which could make others fail, I didn't
check).
Linus
-
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