From: Duy Nguyen <pclouds@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v2] core: use env variable instead of config var to turn on logging pack access
Date: Tue, 4 Jun 2013 14:48:04 +0700 [thread overview]
Message-ID: <CACsJy8BwKfzU0KOPpsPUb601HVpMPWiMAjctHLdpcOSUUUxfGw@mail.gmail.com> (raw)
In-Reply-To: <7vzjv68k8b.fsf@alter.siamese.dyndns.org>
On Tue, Jun 4, 2013 at 1:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> > Have you ever tested this?
>> >
>> > Once log_pack_access goes to NULL (e.g. when it sees the empty
>> > string it was initialized to), this new test will happily
>> > dereference NULL.
>>
>> My bad. I did test when GIT_TRACE_PACK_ACCESS was set, not when it
>> was set to an empty string. All cases tested now.
>>
>> @@ -1956,6 +1958,14 @@ static void write_pack_access_log(struct packed_git *p, off_t obj_offset)
>> {
>> static FILE *log_file;
>>
>> + if (!*log_pack_access) {
>
> The first time, we will see the static empty string and come into
> this block...
>
>> + log_pack_access = getenv("GIT_TRACE_PACK_ACCESS");
>> + if (log_pack_access && !*log_pack_access)
>> + log_pack_access = NULL;
>> + if (!log_pack_access)
>> + return;
>> + }
>
> This may
>
> (1) not find the env-var, in which case log_pack_access becomes
> NULL here, and the function returns.
>
> (2) find the env-var to be an empty string, in which case
> log_pack_access becomes NULL in the next statement, and the
> function returns.
>
> (3) find the env-var to be a non-empty string, and the function
> does not return.
>
> And the next time around, (3) above may work fine; the first if()
> will fail and we do not come in. But in either (1) or (2), don't
> you keep checking the environment every time you come here?
>
> Oh, no, it is worse than that. Either case you set the variable to
> NULL, so the very first "if (!*log_pack_access)" would dereference
> NULL.
You found it out already. The only caller does this
if (log_pack_access) write_pack_access_log(p, obj_offset);
so in (1) and (2), write_pack_access_log() will never be called again.
Originally I had "log_pack_access && !*log_pack_access" in the first
if(), but I dropped it because of the caller's condition. It's a bit
fragile though. Imagine a new callsite is added.. (to be continued)
> Why not start from NULL:
>
> static const char *log_pack_access;
>
> treat that NULL as "unknown" state, and avoid running getenv over
> and over again by treating non-NULL value as "known"? Perhaps like
> this?
>
> if (!log_pack_access) {
> /* First time: is env set? */
> log_pack_access = getenv("GIT_TRACE_PACK_ACCESS");
> if (!log_pack_access)
> log_pack_access = "";
or set log_pack_access to SomePredefinedButUselessString here. I
wanted to do this but couldn't because of global variable
initialization.
> }
> /* Now GIT_TRACE_PACK_ACCESS is known */
> if (!*log_pack_access)
> return; /* not wanted */
>
> As you can no longer rely on "config is read before we do anything
> else" by switching to lazy env checking, your guard at the caller
> needs to be updated, if you want to reduce unneeded call-return
> overhead:
>
> if (!log_pack_access || *log_pack_access)
> write_pack_access_log(...);
and this turns to "if (!log_.. || log != SomePrede...)", no more
peeking into log_pack_access.
>
> But the guard is purely for performance, not correctness, because
> the function now does the "return no-op if we know we are not
> wanted" itself.
(continued here) ..so yeah this looks better.
> Also you no longer need to have an extern variable in environment.c
will fix.
--
Duy
prev parent reply other threads:[~2013-06-04 7:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 13:51 [PATCH 1/2] core: use env variable instead of config var to turn on logging pack access Nguyễn Thái Ngọc Duy
2013-05-30 13:51 ` [PATCH 2/2] git.txt: document GIT_TRACE_PACKET Nguyễn Thái Ngọc Duy
2013-06-03 20:24 ` [PATCH 1/2] core: use env variable instead of config var to turn on logging pack access Junio C Hamano
2013-06-03 22:52 ` [PATCH v2] " Nguyễn Thái Ngọc Duy
2013-06-04 6:26 ` Junio C Hamano
2013-06-04 7:48 ` Duy Nguyen [this message]
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=CACsJy8BwKfzU0KOPpsPUb601HVpMPWiMAjctHLdpcOSUUUxfGw@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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).