From: "Frank Ch. Eigler" <fche@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org, amerey@redhat.com
Subject: Re: patch 2/2 debuginfod server etc.
Date: Fri, 15 Nov 2019 19:54:00 -0000 [thread overview]
Message-ID: <20191115195439.GC15272@redhat.com> (raw)
In-Reply-To: <5356c862142d3221d91dc3f8767d6659639c61d9.camel@klomp.org>
Hi -
> And I don't like the pretty big testfiles, which aren't self-contained.
> You have to fetch them from a remote koji server. It would be much
> better to have a (small) self-contained .spec file that can be used to
> generate the rpms. Frank is already working on that.
Well, one did not have to fetch them from anywhere, they were already
there. But yes, working on a smaller synthetic set of RPMs.
> > +debuginfod_build_id_find_LDADD = $(libdw)
>
> You also use libelf functions, they'll be pulled in through libdw, but
> I think it is better to be explicit
> debuginfod_build_id_find_LDADD = $(libelf) $(libdw)
OK.
> > +set -x
>
> Is this really necessary?
> It makes the log files very verbose.
> Or is that the intention?
I've found it tricky to debug failing tests without this.
> > +# find an unused port number
> > +while true; do
> > + PORT1=`expr '(' $RANDOM % 1000 ')' + 9000`
> > + ss -atn | fgrep ":$PORT1" || break
> > +done
>
> Which package does ss come from?
iproute-5.2.0-1.fc30.x86_64
> Make sure it is listed as a BuildRequires.
OK, because of %check in the RPM?
> Also I am slightly worried about it not finding anything and looping
> forever. Probably unlikely, but ss might misfunction?
There is no 100%-probable way of assigning a port number ahead of
time. Would you like an iteration limit / abort for that unlikely
situation?
> What happens if ss isn't installed?
The set -e should nuke the test run.
> If we assume bash (which I believe we already do in some places) you
> could use the bash builtin special /dev/tcp redirection to test whether
> a localhost port is open with echo >/dev/tcp/localhost/$PORT
OK, will try that.
> > +mkdir F R
> > +tempfiles F R
>
> O, they are directories, then yeah, tempfiles isn't enough.
> Maybe don't mark them as tempfiles then.
OK.
> > +env LD_LIBRARY_PATH=$ldpath DEBUGINFOD_URLS= ${abs_builddir}/../debuginfod/debuginfod -vvvv -d $DB \
> > +-p $PORT1 -t0 -g0 R F &
> > +PID1=$!
> > +sleep 3
>
> Is there no better way to test the server has started?
This one may not be needed.
> > +export DEBUGINFOD_URLS=http://localhost:$PORT1/ # or without trailing /
> > +
> > +# We use -t0 and -g0 here to turn off time-based scanning & grooming.
> > +# For testing purposes, we just sic SIGUSR1 / SIGUSR2 at the process.
> > +
> > +########################################################################
> > +
> > +# Compile a simple program, strip its debuginfo and save the build-id.
> > +# Also move the debuginfo into another directory so that elfutils
> > +# cannot find it without debuginfod.
> > +echo "int main() { return 0; }" > ${PWD}/prog.c
> > +tempfiles prog.c
> > +gcc -g -o prog ${PWD}/prog.c
> > + ${abs_top_builddir}/src/strip -g -f prog.debug ${PWD}/prog
> > +BUILDID=`env LD_LIBRARY_PATH=$ldpath ${abs_builddir}/../src/readelf \
> > + -a prog | grep 'Build ID' | cut -d ' ' -f 7`
> > +
> > +mv prog F
> > +mv prog.debug F
> > +kill -USR1 $PID1
> > +sleep 3 # give enough time for scanning pass
>
> Hmm that hardcoded sleep 3 again :{
Well, here's the problem. We want to assert that the scan was
successful. We can't just reject a 404 response because the scan may
not have finished yet. So we'd have to race/loop/poll. But then we'd
need a timeout (how long?). It turns out to be the same thing, just
more complicated.
> > +mv testfile-debuginfod-0.rpm R
> > +mv testfile-debuginfod-1.rpm R
> > +mv testfile-debuginfod-2.rpm R
> > +kill -USR1 $PID1
> > +sleep 10
>
> Why 10?
To give extra time for scanning RPMs.
> > +kill -USR1 $PID1 # two hits of SIGUSR1 may be needed to resolve .debug->dwz->srefs
> > +sleep 10
>
> And another :{
Yes, again, same reasons as above. You can either have a timeout-poll
loop, or a time sleep and a single judgement poll.
> > +# Trigger a cache clean and run the tests again. The clients should be unable to
> > +# find the target.
> > +echo 0 > $DEBUGINFOD_CACHE_PATH/cache_clean_interval_s
> > +echo 0 > $DEBUGINFOD_CACHE_PATH/max_unused_age_s
> > +
> > +testrun ${abs_builddir}/debuginfod_build_id_find -e F/prog 1
> > +
> > +testrun ${abs_top_builddir}/debuginfod/debuginfod-find debuginfo $BUILDID2 && false || true
>
> OK. But that means zero means never cache/always clean?
> I would have expected 0 to mean "forever".
I see the man page doesn't specifically disclose the interpretation of
zero. A "no retention of prior results" purpose is useful, and is
consistent with 0 as per the text. A "retain forever" setting would
have to be a different value.
- FChE
next prev parent reply other threads:[~2019-11-15 19:54 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-28 19:04 patch 0/2 debuginfod submission Frank Ch. Eigler
2019-10-28 19:06 ` patch 1/2 debuginfod client Frank Ch. Eigler
2019-10-28 19:09 ` patch 2/2 debuginfod server etc Frank Ch. Eigler
2019-11-04 21:48 ` patch 3/3 debuginfod client interruptability Frank Ch. Eigler
2019-11-07 9:07 ` patch 4 debuginfod: symlink following mode Frank Ch. Eigler
2019-11-07 9:08 ` patch 5 debuginfod: prometheus metrics Frank Ch. Eigler
2019-11-15 17:26 ` Mark Wielaard
2019-11-15 17:58 ` Frank Ch. Eigler
2019-11-18 16:20 ` Mark Wielaard
2019-11-18 16:48 ` Frank Ch. Eigler
2019-11-19 16:13 ` Mark Wielaard
2019-11-15 16:49 ` patch 4 debuginfod: symlink following mode Mark Wielaard
2019-11-15 18:31 ` Frank Ch. Eigler
2019-11-18 16:27 ` Mark Wielaard
2019-11-15 16:16 ` patch 3/3 debuginfod client interruptability Mark Wielaard
2019-11-15 17:03 ` Aaron Merey
2019-11-15 17:35 ` Mark Wielaard
2019-11-15 18:14 ` Pedro Alves
2019-11-17 23:44 ` Mark Wielaard
2019-11-18 2:50 ` Frank Ch. Eigler
2019-11-18 9:24 ` Pedro Alves
2019-11-19 12:58 ` Mark Wielaard
2019-11-13 17:22 ` patch 2/2 debuginfod server etc Mark Wielaard
2019-11-14 11:54 ` Frank Ch. Eigler
2019-11-16 1:31 ` Mark Wielaard
2019-11-13 23:19 ` Mark Wielaard
2019-11-14 12:30 ` Frank Ch. Eigler
2019-11-18 14:17 ` Mark Wielaard
2019-11-18 18:41 ` Frank Ch. Eigler
2019-11-19 15:41 ` Mark Wielaard
2019-11-19 16:13 ` Frank Ch. Eigler
2019-11-19 20:11 ` Mark Wielaard
2019-11-19 21:15 ` Frank Ch. Eigler
2019-11-20 11:53 ` Mark Wielaard
2019-11-20 12:29 ` Frank Ch. Eigler
2019-11-21 14:16 ` Mark Wielaard
2019-11-21 15:40 ` Mark Wielaard
2019-11-21 16:01 ` Frank Ch. Eigler
2019-11-21 15:58 ` Frank Ch. Eigler
2019-11-21 16:37 ` Mark Wielaard
2019-11-21 17:18 ` Frank Ch. Eigler
2019-11-21 20:42 ` Mark Wielaard
2019-11-22 12:08 ` Mark Wielaard
2019-11-14 20:45 ` Mark Wielaard
2019-11-15 11:03 ` Mark Wielaard
2019-11-15 21:00 ` Frank Ch. Eigler
2019-11-18 15:01 ` Mark Wielaard
2019-11-15 14:40 ` Mark Wielaard
2019-11-15 19:54 ` Frank Ch. Eigler [this message]
2019-11-18 15:31 ` Mark Wielaard
2019-11-18 15:49 ` Frank Ch. Eigler
2019-11-12 11:12 ` patch 1/2 debuginfod client Mark Wielaard
2019-11-12 15:14 ` Frank Ch. Eigler
2019-11-12 21:59 ` Mark Wielaard
2019-11-14 0:33 ` Frank Ch. Eigler
2019-11-15 21:33 ` Mark Wielaard
2019-11-12 21:25 ` Mark Wielaard
2019-11-13 23:25 ` Frank Ch. Eigler
2019-11-16 0:46 ` Mark Wielaard
2019-11-16 18:53 ` Frank Ch. Eigler
2019-11-18 17:17 ` Mark Wielaard
2019-11-18 20:33 ` Frank Ch. Eigler
2019-11-19 15:57 ` Mark Wielaard
2019-11-19 16:20 ` Frank Ch. Eigler
2019-11-19 20:16 ` Mark Wielaard
2019-11-19 21:22 ` Frank Ch. Eigler
2019-11-20 12:50 ` Mark Wielaard
2019-11-20 13:30 ` Frank Ch. Eigler
2019-11-21 14:02 ` Mark Wielaard
2019-11-13 13:57 ` Mark Wielaard
2019-11-14 11:24 ` Frank Ch. Eigler
2019-11-16 0:52 ` Mark Wielaard
2019-11-16 2:28 ` Frank Ch. Eigler
2019-10-30 11:04 ` patch 0/2 debuginfod submission Mark Wielaard
2019-10-30 13:40 ` Frank Ch. Eigler
2019-10-30 14:12 ` Mark Wielaard
2019-10-30 18:11 ` Frank Ch. Eigler
2019-10-31 11:18 ` 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=20191115195439.GC15272@redhat.com \
--to=fche@redhat.com \
--cc=amerey@redhat.com \
--cc=elfutils-devel@sourceware.org \
--cc=mark@klomp.org \
/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).