git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Riesen <alexander.riesen@cetitec.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, "Elijah Newren" <newren@gmail.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: Crashes in t/t4058-diff-duplicates.sh
Date: Fri, 6 May 2022 12:18:28 +0200	[thread overview]
Message-ID: <YnT19KB2XkBrJOLQ@pflmari> (raw)
In-Reply-To: <YnSWgDdxgm+XWiLt@nand.local>

Taylor Blau, Fri, May 06, 2022 05:31:12 +0200:
> On Thu, May 05, 2022 at 10:53:45AM +0200, Alex Riesen wrote:
> > Hi,
> >
> > the test t4058-diff-duplicates reliably dumps core here:
> 
> It was a little tricky to find out what part of t4058 you were referring
> to, but...

Very sorry! I forgot to include the output of the test itself!

> > Core was generated by `/home/xxx/yyyyyyy/git/git merge update'.
> 
> ...helps us out ;-). The only match for "git merge update" is in
> t4058.16, which blames back to ac14de13b2 (t4058: explore duplicate tree
> entry handling in a bit more detail, 2020-12-11), which helpfully
> explains that this segfault is known (and furthermore they are
> long-lived and likely not even worth fixing, per ac14de13b2).

Thanks for finding the commit! Makes absolutely sense, but...

I have a little problem with the approach to have it crashing though.
It crashes for every run of the tests: I have a crash core collecting program
on the machine I use to build binaries of the tools I use. While it is not
hard to isolate builds of Git (as a whole) with coredump collecting switched
off I'd prefer to not do it: it's a special case (which gets forgotten) and
with it I'll miss new crashes in Git (which I might have authored).
It is inconvenient to crash regularly.

Is it reasonable to ask to replace the crash in case of this known breakage
with an error()+exit(130)? (`exit(130)` because the test_expect_failure seems
to require an exit code greater than 129, and I failed to find where it is).

Or, since the test-lib already has a notion of "expected failure" provide
the *tests* with a way to reduce collateral effects of that failure?
Like below with the GDB.

Regards,
Alex

diff --git a/t/t4058-diff-duplicates.sh b/t/t4058-diff-duplicates.sh
index 54614b814d..b2f9ab07d1 100755
--- a/t/t4058-diff-duplicates.sh
+++ b/t/t4058-diff-duplicates.sh
@@ -132,22 +132,38 @@ test_expect_success 'create a few commits' '
 	rm commit_id up final
 '
 
+may_crash() {
+	local ret
+	if test -n "$GIT_DEBUGGER"
+	then
+		"$@"
+		ret=$?
+	else
+		GIT_DEBUGGER="gdb --batch --return-child-result --nh -ex run --args"
+		export GIT_DEBUGGER
+		"$@"
+		ret=$?
+		unset GIT_DEBUGGER
+	fi
+	return $ret
+}
+
 test_expect_failure 'git read-tree does not segfault' '
 	test_when_finished rm .git/index.lock &&
-	test_might_fail git read-tree --reset base
+	test_might_fail may_crash git read-tree --reset base
 '
 
 test_expect_failure 'reset --hard does not segfault' '
 	test_when_finished rm .git/index.lock &&
 	git checkout base &&
-	test_might_fail git reset --hard
+	test_might_fail may_crash git reset --hard
 '
 
 test_expect_failure 'git diff HEAD does not segfault' '
 	git checkout base &&
 	GIT_TEST_CHECK_CACHE_TREE=false &&
 	git reset --hard &&
-	test_might_fail git diff HEAD
+	test_might_fail may_crash git diff HEAD
 '
 
 test_expect_failure 'can switch to another branch when status is empty' '
@@ -183,7 +199,7 @@ test_expect_success 'switch to base branch and force status to be clean' '
 '
 
 test_expect_failure 'fast-forward from duplicate entries to non-duplicate' '
-	git merge update
+	may_crash git merge update
 '
 
 test_done

  parent reply	other threads:[~2022-05-06 10:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05  8:53 Crashes in t/t4058-diff-duplicates.sh Alex Riesen
     [not found] ` <YnSWgDdxgm+XWiLt@nand.local>
2022-05-06 10:18   ` Alex Riesen [this message]
2022-05-06 16:30     ` Junio C Hamano
2022-05-07  4:14       ` Elijah Newren
2022-05-09 15:23         ` Taylor Blau
2022-05-10  3:50           ` Elijah Newren
2022-05-09 12:51       ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnT19KB2XkBrJOLQ@pflmari \
    --to=alexander.riesen@cetitec.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).