All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.