From: Thomas Rast Date: Wed, 30 Nov 2011 16:56:32 GMT Subject: Re: [PATCH 3/3] fast-export: output reset command for commandline revs Message-ID: <201111301756.32305.trast@student.ethz.ch> In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com> Sverre Rabbelier wrote: > When a revision is specified on the commandline we explicitly output > a 'reset' command for it if it was not handled already. This allows > for example the remote-helper protocol to use fast-export to create > branches that point to a commit that has already been exported. > > Initial-patch-by: Johannes Schindelin > Signed-off-by: Sverre Rabbelier My apologies if this is redundant, I'm not up to speed on progress here. But a crash in t9350.19 caught my eye: checking known breakage: ( cd limit-by-paths && git fast-export master~2..master~1 > output && test_cmp output expected ) ==23766== Invalid read of size 1 ==23766== at 0x4FD21E: prefixcmp (strbuf.c:9) ==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563) ==23766== by 0x42C274: cmd_fast_export (fast-export.c:732) ==23766== by 0x4051F1: run_builtin (git.c:308) ==23766== by 0x40538B: handle_internal_command (git.c:466) ==23766== by 0x4054A5: run_argv (git.c:512) ==23766== by 0x40562C: main (git.c:585) ==23766== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==23766== { Memcheck:Addr1 fun:prefixcmp fun:handle_tags_and_duplicates fun:cmd_fast_export fun:run_builtin fun:handle_internal_command fun:run_argv fun:main } ==23766== ==23766== Process terminating with default action of signal 11 (SIGSEGV) ==23766== Access not within mapped region at address 0x0 ==23766== at 0x4FD21E: prefixcmp (strbuf.c:9) ==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563) ==23766== by 0x42C274: cmd_fast_export (fast-export.c:732) ==23766== by 0x4051F1: run_builtin (git.c:308) ==23766== by 0x40538B: handle_internal_command (git.c:466) ==23766== by 0x4054A5: run_argv (git.c:512) ==23766== by 0x40562C: main (git.c:585) The crash is hidden by the fact that the test is test_expect_failure. It bisects to this commit. Perhaps we should distinguish between test_expect_failure and test_expect_crash?... -- Thomas Rast trast@{inf,student}.ethz.ch