trace2: prevent segfault on config collection where no value specified #1814

ad-murray · 2024-10-08T04:30:40Z

gitgitgadget · 2024-10-08T04:31:26Z

Welcome to GitGitGadget

Hi @ad-murray, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that either:

Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.

You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <[email protected]>, Ill Takalook <[email protected]>

NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description,
because it will result in a malformed CC list on the mailing list. See
example.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

the lines should not exceed 76 columns,
the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
the commit messages' body should be describing the "why?" of the change.
Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

gitgitgadget · 2024-10-08T04:31:28Z

There are issues in commit 2d4ddcf:
add null check for config value
Commit checks stopped - the message is too short
Commit not signed off

Haizzz · 2024-10-08T04:36:25Z

/allow ad-murray

gitgitgadget · 2024-10-08T04:37:04Z

User ad-murray is now allowed to use GitGitGadget.

WARNING: ad-murray has no public email address set on GitHub;
GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

gitgitgadget · 2024-10-08T04:53:13Z

There are issues in commit 976bdf6:
Prevent segfault on trace2 config collection where no value specified
Commit checks stopped - the message is too short
Commit not signed off

gitgitgadget · 2024-10-08T05:06:18Z

There are issues in commit b696097:
trace2: prevent segfault on config collection where no value specified
Commit checks stopped - the message is too short
Commit not signed off

dscho · 2024-10-08T06:43:42Z

Commit checks stopped - the message is too short

Please follow the guidance in https://github.blog/2022-06-30-write-better-commits-build-better-projects/ to improve it, in particular with a strong focus on this part:

	What you’re doing	Why you’re doing it
High-level (strategic)	Intent (what does this accomplish?)	Context (why does the code do what it does now?)
Low-level (tactical)	Implementation (what did you do to accomplish your goal?)	Justification (why is this change being made?)

In this instance, the commit message could explain, for example, why the !strlen(value) condition is needed, i.e. how a non-NULL but still empty value could lead to a segmentation fault and where in the code that would happen.

Commit not signed off

The Git project requires you to "sign off" your work, please amend the commit accordingly and force-push.

gitgitgadget · 2024-10-08T23:16:15Z

There are issues in commit 9b505b7:
trace2: prevent segfault on config collection where no value specified
Lines in the body of the commit messages should be wrapped between 60 and 76 characters.
Indented lines, and lines without whitespace, are exempt

gitgitgadget · 2024-10-08T23:18:19Z

There are issues in commit 48ffb81:
trace2: prevent segfault on config collection where no value specified
Lines in the body of the commit messages should be wrapped between 60 and 76 characters.
Indented lines, and lines without whitespace, are exempt

ad-murray · 2024-10-09T23:13:46Z

Commit checks stopped - the message is too short

Please follow the guidance in https://github.blog/2022-06-30-write-better-commits-build-better-projects/ to improve it, in particular with a strong focus on this part:

What you’re doing Why you’re doing it
High-level (strategic) Intent (what does this accomplish?) Context (why does the code do what it does now?)
Low-level (tactical) Implementation (what did you do to accomplish your goal?) Justification (why is this change being made?)
In this instance, the commit message could explain, for example, why the !strlen(value) condition is needed, i.e. how a non-NULL but still empty value could lead to a segmentation fault and where in the code that would happen.

Commit not signed off

The Git project requires you to "sign off" your work, please amend the commit accordingly and force-push.

Commit message updated, is there a way to re-run the failing checks?

dscho · 2024-10-10T10:32:59Z

is there a way to re-run the failing checks?

Well, those checks fail because the patch introduces a regression. In particular t1300.131 documents that git -c foo.flag config --bool foo.flag should return true, not an error.

Speaking of test cases: You described one in the commit message. How about moving it from the commit message into an actual test script, to verify that the described regression is fixed (and to prevent future regressions going unnoticed)? t0210-trace2-normal.sh would make for a fine home for that test case.

As to the fix for the segmentation fault: I think this diff, or a variation thereof, should be the correct fix:

diff --git a/trace2.c b/trace2.c
index f894532d0533..6cae41ca61c4 100644
--- a/trace2.c
+++ b/trace2.c
@@ -259,7 +259,7 @@ static const char *redact_arg(const char *arg)
 	const char *p, *colon;
 	size_t at;
 
-	if (!trace2_redact ||
+	if (!trace2_redact || !arg ||
 	    (!skip_prefix(arg, "https://", &p) &&
 	     !skip_prefix(arg, "http://", &p)))
 		return arg;

ad-murray · 2024-10-10T22:05:24Z

right you are, will do

ad-murray · 2024-11-01T07:11:18Z

/submit

ad-murray · 2024-11-03T22:59:47Z

/submit

ad-murray · 2024-11-04T00:46:33Z

/submit

gitgitgadget · 2024-11-04T08:38:58Z

Error: Ignoring PR with empty title and/or body

dscho · 2024-11-04T08:48:59Z

Error: Ignoring PR with empty title and/or body

@ad-murray This means that GitGitGadget requires a cover letter (which is composed of the PR title, and the PR description, i.e. the initial comment).

However, in this instance I am convinced that you do not want to contribute three patches; Instead, you will want to "squash" them into a single commit. Once you do that, you do not need to populate the initial comment with content for a cover letter, as none will be sent for single-patch contributions, as per the Git maintainer's request.

gitgitgadget · 2024-11-06T23:50:05Z

There are issues in commit 2253303:
trace2: prevent segfault on config collection where no value specified
Commit not signed off

When TRACE2 analytics is enabled, a git config option that has no value causes a segfault. Steps to Reproduce GIT_TRACE2=true GIT_TRACE2_CONFIG_PARAMS=status.* git -c status.relativePaths version Expected Result git version 2.46.0 Actual Result zsh: segmentation fault GIT_TRACE2=true This adds a null check to prevent the segfault and instead return the "empty config value" error. Signed-off-by: Adam Murray <[email protected]>

ad-murray · 2024-11-07T00:02:36Z

/submit

gitgitgadget · 2024-11-07T00:05:03Z

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1814/ad-murray/fix-trace2-segfault-v1

To fetch this version to local tag pr-1814/ad-murray/fix-trace2-segfault-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1814/ad-murray/fix-trace2-segfault-v1

gitgitgadget · 2024-11-07T02:03:27Z

On the Git mailing list, Jeff King wrote (reply to this):

On Thu, Nov 07, 2024 at 12:04:48AM +0000, Adam Murray via GitGitGadget wrote:

> When TRACE2 analytics is enabled, a git config option that has no value
> causes a segfault.
> 
> Steps to Reproduce
> GIT_TRACE2=true GIT_TRACE2_CONFIG_PARAMS=status.*
> git -c status.relativePaths version
> Expected Result
> git version 2.46.0
> Actual Result
> zsh: segmentation fault GIT_TRACE2=true
> 
> This adds a null check to prevent the segfault and instead return
> the "empty config value" error.

We definitely should deal with the NULL here, but I'm not sure that
returning an error is correct. A value-less config like this is a
synonym for "true". If the point of this code is to dump a trace of
config settings, then by returning without printing anything, we're
misleading the user.

I.e., doing this, with an explicit value for the config option:

  GIT_TRACE2=true GIT_TRACE2_CONFIG_PARAMS=status.* git -c status.relativePaths=true version

should (and does) show:

  20:48:11.662470 trace2.c:437                      def_param scope:command status.relativepaths=true

If we swap that our for "-c status.relativePaths", then the outcome is
the same: we've turned on that config option. But with your patch, the
trace won't mention it at all.

> diff --git a/trace2.c b/trace2.c
> index f894532d053..5df43478b8f 100644
> --- a/trace2.c
> +++ b/trace2.c
> @@ -759,7 +759,7 @@ void trace2_def_param_fl(const char *file, int line, const char *param,
>  	int j;
>  	const char *redacted;
>  
> -	if (!trace2_enabled)
> +	if (!trace2_enabled || !value)
>  		return;
>  
>  	redacted = redact_arg(value);

So here I think we need to either:

  1. Just quietly substitute "true" for the value. For a bool, the two
     are equivalent, and this is probably an acceptable fiction for a
     trace to show. For a non-bool (e.g., something like "author.name"),
     though, it's an error, and the trace is somewhat misleading.

  2. Put in some special marker for the NULL value. Something like
     "(null)" works, but it's ambiguous with a config of the same value
     (which obviously you wouldn't expect in normal use, but since the
     point of tracing is often to debug, I could see it being
     misleading).

All of this is made harder by the fact that there are multiple output
targets. So you'd have to pass the NULL down to them and let them handle
it. Something like:

diff --git a/trace2.c b/trace2.c
index 5df43478b8..e67edf4b1b 100644
--- a/trace2.c
+++ b/trace2.c
@@ -759,10 +759,10 @@ void trace2_def_param_fl(const char *file, int line, const char *param,
 	int j;
 	const char *redacted;
 
-	if (!trace2_enabled || !value)
+	if (!trace2_enabled)
 		return;
 
-	redacted = redact_arg(value);
+	redacted = value ? redact_arg(value) : NULL;
 
 	for_each_wanted_builtin (j, tgt_j)
 		if (tgt_j->pfn_param_fl)
diff --git a/trace2/tr2_tgt_normal.c b/trace2/tr2_tgt_normal.c
index baef48aa69..924736ab36 100644
--- a/trace2/tr2_tgt_normal.c
+++ b/trace2/tr2_tgt_normal.c
@@ -307,8 +307,9 @@ static void fn_param_fl(const char *file, int line, const char *param,
 	enum config_scope scope = kvi->scope;
 	const char *scope_name = config_scope_name(scope);
 
-	strbuf_addf(&buf_payload, "def_param scope:%s %s=%s", scope_name, param,
-		    value);
+	strbuf_addf(&buf_payload, "def_param scope:%s %s", scope_name, param);
+	if (value)
+		strbuf_addf(&buf_payload, "=%s", value);
 	normal_io_write_fl(file, line, &buf_payload);
 	strbuf_release(&buf_payload);
 }

but you'd need to do the same for each target implementation.

-Peff

gitgitgadget · 2024-11-07T02:03:29Z

User Jeff King <[email protected]> has been added to the cc: list.

gitgitgadget · 2024-11-07T03:06:47Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

Jeff King <[email protected]> writes:

> I.e., doing this, with an explicit value for the config option:
>
>   GIT_TRACE2=true GIT_TRACE2_CONFIG_PARAMS=status.* git -c status.relativePaths=true version
>
> should (and does) show:
>
>   20:48:11.662470 trace2.c:437                      def_param scope:command status.relativepaths=true
>
> If we swap that our for "-c status.relativePaths", then the outcome is
> the same: we've turned on that config option. But with your patch, the
> trace won't mention it at all.

which may be improvement, but ideally, the "valueless truth" case
should be given differently, perhaps like 

   20:48:11.662470 trace2.c:437                      def_param scope:command status.relativepaths

to allow showing what exactly the system has seen.  After all, trace
output is often used for debugging, and it is not unusual for a
buggy code path to behave on explicit truth and valueless truth
differently.

> So here I think we need to either:
>
>   1. Just quietly substitute "true" for the value. For a bool, the two
>      are equivalent, and this is probably an acceptable fiction for a
>      trace to show. For a non-bool (e.g., something like "author.name"),
>      though, it's an error, and the trace is somewhat misleading.
>
>   2. Put in some special marker for the NULL value. Something like
>      "(null)" works, but it's ambiguous with a config of the same value
>      (which obviously you wouldn't expect in normal use, but since the
>      point of tracing is often to debug, I could see it being
>      misleading).
>
> All of this is made harder by the fact that there are multiple output
> targets. So you'd have to pass the NULL down to them and let them handle
> it. Something like:
> ...
> diff --git a/trace2/tr2_tgt_normal.c b/trace2/tr2_tgt_normal.c
> index baef48aa69..924736ab36 100644
> --- a/trace2/tr2_tgt_normal.c
> +++ b/trace2/tr2_tgt_normal.c
> @@ -307,8 +307,9 @@ static void fn_param_fl(const char *file, int line, const char *param,
>  	enum config_scope scope = kvi->scope;
>  	const char *scope_name = config_scope_name(scope);
>  
> -	strbuf_addf(&buf_payload, "def_param scope:%s %s=%s", scope_name, param,
> -		    value);
> +	strbuf_addf(&buf_payload, "def_param scope:%s %s", scope_name, param);
> +	if (value)
> +		strbuf_addf(&buf_payload, "=%s", value);

Yes, exactly.

>  	normal_io_write_fl(file, line, &buf_payload);
>  	strbuf_release(&buf_payload);
>  }
>
> but you'd need to do the same for each target implementation.

Thanks.

gitgitgadget bot added the new user label Oct 8, 2024

ad-murray force-pushed the fix-trace2-segfault branch from 2d4ddcf to 976bdf6 Compare October 8, 2024 04:52

ad-murray changed the title ~~add null check for config value~~ Prevent segfault on trace2 config collection where no value specified Oct 8, 2024

ad-murray force-pushed the fix-trace2-segfault branch from 976bdf6 to b696097 Compare October 8, 2024 05:05

ad-murray changed the title ~~Prevent segfault on trace2 config collection where no value specified~~ trace2: prevent segfault on config collection where no value specified Oct 8, 2024

ad-murray force-pushed the fix-trace2-segfault branch from b696097 to 9b505b7 Compare October 8, 2024 23:15

ad-murray force-pushed the fix-trace2-segfault branch from 9b505b7 to 48ffb81 Compare October 8, 2024 23:17

ad-murray force-pushed the fix-trace2-segfault branch from 48ffb81 to c35764e Compare October 8, 2024 23:20

ad-murray force-pushed the fix-trace2-segfault branch 2 times, most recently from 0c5d185 to 25cd431 Compare October 31, 2024 06:11

ad-murray force-pushed the fix-trace2-segfault branch from fe611b8 to b4e30d8 Compare November 3, 2024 23:06

ad-murray mentioned this pull request Nov 4, 2024

GitGitGadget PR Handler Pipeline Failures gitgitgadget/gitgitgadget#1747

Open

ad-murray force-pushed the fix-trace2-segfault branch from b4e30d8 to 2253303 Compare November 6, 2024 23:47

ad-murray force-pushed the fix-trace2-segfault branch from 2253303 to 24ba9db Compare November 6, 2024 23:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

trace2: prevent segfault on config collection where no value specified #1814

trace2: prevent segfault on config collection where no value specified #1814

ad-murray commented Oct 8, 2024 •

edited by gitgitgadget bot

Loading

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

Haizzz commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

dscho commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

ad-murray commented Oct 9, 2024

dscho commented Oct 10, 2024

ad-murray commented Oct 10, 2024

ad-murray commented Nov 1, 2024

ad-murray commented Nov 3, 2024

ad-murray commented Nov 4, 2024

gitgitgadget bot commented Nov 4, 2024

dscho commented Nov 4, 2024

gitgitgadget bot commented Nov 6, 2024

ad-murray commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

trace2: prevent segfault on config collection where no value specified #1814

Are you sure you want to change the base?

trace2: prevent segfault on config collection where no value specified #1814

Conversation

ad-murray commented Oct 8, 2024 • edited by gitgitgadget bot Loading

gitgitgadget bot commented Oct 8, 2024

Welcome to GitGitGadget

Contributing the patches

Need help?

gitgitgadget bot commented Oct 8, 2024

Haizzz commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

dscho commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

gitgitgadget bot commented Oct 8, 2024

ad-murray commented Oct 9, 2024

dscho commented Oct 10, 2024

ad-murray commented Oct 10, 2024

ad-murray commented Nov 1, 2024

ad-murray commented Nov 3, 2024

ad-murray commented Nov 4, 2024

gitgitgadget bot commented Nov 4, 2024

dscho commented Nov 4, 2024

gitgitgadget bot commented Nov 6, 2024

ad-murray commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

gitgitgadget bot commented Nov 7, 2024

ad-murray commented Oct 8, 2024 •

edited by gitgitgadget bot

Loading