From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
Git Mailing List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()
Date: Wed, 2 May 2018 09:41:39 +0200 (DST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1805020930340.73@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqvac6wwrw.fsf@gitster-ct.c.googlers.com>
Hi,
On Wed, 2 May 2018, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin
> > <johannes.schindelin@gmx.de> wrote:
> >> t1406 specifically verifies that certain code paths fail with a BUG: ...
> >> message.
> >>
> >> In the upcoming commit, we will convert that message to be generated via
> >> BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a
> >> regular exit code.
> >
> > On the other hand, SIGABRT on linux creates core dumps. And on some
> > setup (like mine) core dumps may be redirected to some central place
> > via /proc/sys/kernel/core_pattern. I think systemd does it too but I
> > didn't check.
> >
> > This moving to SIGABRT when we know it _will_ happen when running the
> > test suite will accumulate core dumps over time and not cleaned up by
> > the test suite. Maybe keeping die("BUG: here is a good compromise.
>
> I do not think it is. At regular runtime, we _do_ want Git to dump
> core if it triggers BUG() condition, whose point is to mark
> conditions that should never happen.
Indeed.
> As discussed in this thread, tests that use t/helper/ executables
> that try to trickle BUG() codepath to ensure that these "should
> never happen" conditions are caught do need to deal with it. If
> dumping core is undesirable, tweaking BUG() implementation so that
> it becomes die("BUG: ...") *ONLY* when the caller knows what it is
> doing (e.g. running t/helper/ commands) is probably a good idea.
> Perhaps GIT_TEST_OPTS can gain one feature "--bug-no-abort" and set
> an environment variable so that implementation of BUG() can notice,
> or something.
I think we can do even better than that. t/helper/*.c could set a global
variable that no other code is supposed to set, to trigger an alternative
to SIGABRT. Something like
-- snip --
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index 87066ced62a..5176f9f20ae 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -47,7 +47,9 @@ static struct test_cmd cmds[] = {
int cmd_main(int argc, const char **argv)
{
int i;
+ extern int BUG_exit_code;
+ BUG_exit_code = 99;
if (argc < 2)
die("I need a test name!");
diff --git a/usage.c b/usage.c
index cdd534c9dfc..9c84dccfa97 100644
--- a/usage.c
+++ b/usage.c
@@ -210,6 +210,9 @@ void warning(const char *warn, ...)
va_end(params);
}
+/* Only set this, ever, from t/helper/, when verifying that bugs are
caught. */
+int BUG_exit_code;
+
static NORETURN void BUG_vfl(const char *file, int line, const char *fmt,
va_list params)
{
char prefix[256];
@@ -221,6 +224,8 @@ static NORETURN void BUG_vfl(const char *file, int
line, const char *fmt, va_lis
snprintf(prefix, sizeof(prefix), "BUG: ");
vreportf(prefix, fmt, params);
+ if (BUG_exit_code)
+ exit(BUG_exit_code);
abort();
}
-- snap --
I'll try to find some time to play with this.
Ciao,
Dscho
>
> When we are testing normal parts of Git outside t/helper/, we never
> want to hit BUG(). Aborting and dumping core when that happens is
> an desirable outcome. From that point of view, the idea in 1/6 of
> this patch series to annotate test_must_fail and say "we know this
> one is going to hit BUG()" is a sound one. The implementation in
> 1/6 to treat SIGABRT as an acceptable failure needs to be replaced
> to instead use the above mechanism you would use to tell BUG() not
> to abort but die with message to arrange that to happen before
> running the git command (most likely something from t/helper/) under
> test_must_fail ok=sigabrt; and then those who regularly break their
> Git being tested (read: us devs) and hit BUG() could instead set the
> environment variable (i.e. internal implementation detail) manually
> in their environment to turn these BUG()s into die("BUG:...)s while
> testing their early mistakes if they do not want core (of course,
> you could just do "ulimit -c", and that may be simpler solution of
> your "testing Git contaminates central core depot" issue).
>
>
>
>
>
>
>
next prev parent reply other threads:[~2018-05-02 7:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 22:17 [PATCH 0/6] Finish the conversion from die("BUG: ...") to BUG() Johannes Schindelin
2018-04-29 22:17 ` [PATCH 1/6] test_must_fail: support ok=sigabrt Johannes Schindelin
2018-04-29 22:17 ` [PATCH 2/6] t1406: prepare for the refs code to fail with BUG() Johannes Schindelin
2018-04-30 19:32 ` Johannes Sixt
2018-05-01 11:04 ` Johannes Schindelin
2018-05-01 11:22 ` Duy Nguyen
2018-05-01 11:26 ` Duy Nguyen
2018-05-02 3:40 ` Junio C Hamano
2018-05-02 7:41 ` Johannes Schindelin [this message]
2018-05-02 10:41 ` Junio C Hamano
2018-04-29 22:18 ` [PATCH 3/6] refs/*: report bugs using the BUG() macro Johannes Schindelin
2018-04-29 22:18 ` [PATCH 4/6] run-command: use BUG() to report bugs, not die() Johannes Schindelin
2018-04-29 22:19 ` [PATCH 5/6] Replace all die("BUG: ...") calls by BUG() ones Johannes Schindelin
2018-04-29 22:19 ` [PATCH 6/6] Convert remaining die*(BUG) messages Johannes Schindelin
2018-04-30 2:53 ` Eric Sunshine
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1805020930340.73@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).