public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Noah Sanci <nsanci@redhat.com>, elfutils-devel@sourceware.org
Subject: Re: [Bug debuginfod/27982] added DEBUGINFOD_MAXSIZE and DEBUGINFOD_MAXTIME
Date: Thu, 29 Jul 2021 15:36:00 +0200	[thread overview]
Message-ID: <34693753bef32fe1583538ca8ca7abe42f7d49a1.camel@klomp.org> (raw)
In-Reply-To: <CAJXA7qjTnL8dwzTZ9p6=+wfNS6mbASngb1jkKK3G3A+k_y__Ng@mail.gmail.com>

Hi Noah,

On Mon, 2021-07-26 at 14:56 -0400, Noah Sanci via Elfutils-devel wrote:
> Please find the attached patch for pr 27982. DEBUGINFOD_MAXSIZE and
> MAXTIME were added in this patch to allow users to use more
> constraints when downloading debuginfo.

This looks good. Some high level comments (because I don't actually
know much about http requests).

Why have MAXTIME default to LONG_MAX? Which is long, but different on
different arches 32/64bit. If MAXSIZE == 0 means infinite, why not make
 MAXTIME=0 the same for consistency?

An alternative of passing around the X-DEBUGINFOD-MAXSIZE header is
doing it all at the client side if we supported HEAD. See PR27277. Did
you consider that route?

The bug suggests to also check the Content-Length header on reciept (in
case the server didn't support or respect the X-DEBUGINFOD-MAXSIZE
header. Did you try to implement that?

I believe various error handling goto out1 should be goto out2 (after
your duplicate urls patch). Could you double check that?

I had to make this little tweak to make the testcase pass on my setup
(because PWD contains symlinks):

diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
index feec5ddf..8ed7743d 100755
--- a/tests/run-debuginfod-find.sh
+++ b/tests/run-debuginfod-find.sh
@@ -187,7 +187,7 @@ tempfiles find-vlog$PORT1
 # wait for the server to fail the same number of times the query is retried.
 wait_ready $PORT1 'http_responses_after_you_milliseconds_count{code="406"}' 1
 # quickly ensure all reporting is functional
-grep 'serving file '${PWD}'/F/p+r%o\$g.debug' vlog$PORT1
+grep 'serving file '$(realpath ${PWD})'/F/p+r%o\$g.debug' vlog$PORT1
 grep 'File too large' vlog$PORT1
 grep 'using max size 1B' find-vlog$PORT1
 if [ -f ${DEBUGINFOD_CACHE_PATH}/${BUILDID} ]; then

Cheers,

Mark

  reply	other threads:[~2021-07-29 13:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 18:56 Noah Sanci
2021-07-29 13:36 ` Mark Wielaard [this message]
2021-07-29 13:58   ` Frank Ch. Eigler
2021-07-29 20:29   ` Noah Sanci
2021-07-30 11:11     ` Mark Wielaard
2021-07-30 13:39       ` Noah Sanci
2021-08-04 13:39         ` Mark Wielaard

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=34693753bef32fe1583538ca8ca7abe42f7d49a1.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=nsanci@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).