On 07/17/2013 09:03 PM, Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes: > >> If do_one_ref() is called recursively, then the inner call should not >> permanently overwrite the value stored in current_ref by the outer >> call. Aside from the tiny optimization loss, peel_ref() expects the >> value of current_ref not to change across a call to peel_entry(). But >> in the presence of replace references that assumption could be >> violated by a recursive call to do_one_ref: >> >> do_for_each_entry() >> do_one_ref() >> builtin/describe.c:get_name() >> peel_ref() >> peel_entry() >> peel_object () >> deref_tag_noverify() >> parse_object() >> lookup_replace_object() >> do_lookup_replace_object() >> prepare_replace_object() >> do_for_each_ref() >> do_for_each_entry() >> do_for_each_entry_in_dir() >> do_one_ref() >> >> The inner call to do_one_ref() was unconditionally setting current_ref >> to NULL when it was done, causing peel_ref() to perform an invalid >> memory access. >> >> So change do_one_ref() to save the old value of current_ref before >> overwriting it, and restore the old value afterward rather than >> setting it to NULL. >> >> Reported by: Mantas Mikulėnas <graw...@gmail.com> >> >> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu> >> --- > > Thanks. > > s/Reported by:/Reported-by:/ and lose the extra blank line after it?
ACK, sorry I got the notation wrong. > I wonder if we can have an easy reproduction recipe in our tests. I could reproduce the problem by following the recipe provided by Mantas upthread (or at least something very close to it; I can't find the script that I was using): > git pack-refs --all --prune > sed -i '/^[#^]/d' .git/packed-refs > git replace -f HEAD $(git --no-replace-objects cat-file commit HEAD \ > | sed 's/@/@test/' | git hash-object --stdin -t commit -w) > ~/src/git/git describe It would be good to document this in the commit message, but I don't think it is necessary to have a test for it in the test suite because I don't think it is the kind of bug that will reappear. I sent the patch shortly before leaving for a trip so I didn't have time to make it as complete as I would have liked. But given that the problem was already in master, and the fix is pretty simple, I wanted to send the fix right away. When I have some time I can fix it up better, or feel free to manhandle the patch and/or commit message yourself if you prefer. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
