public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: ☠ Buildbot (Wildebeest Builder): elfutils - failed test (failure) (master)
Date: Thu, 14 Apr 2022 13:30:54 +0200	[thread overview]
Message-ID: <c73b4e9a13d337fc61fa4c0e94ca36d3737a5084.camel@klomp.org> (raw)
In-Reply-To: <20220413190937.GA1503@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Hi Frank,

On Wed, 2022-04-13 at 15:09 -0400, Frank Ch. Eigler wrote:
> > So maybe corruptin the sqlite database prevents a proper shutdown
> > of the debuginfod process?
> 
> Yeah, that test is a bit blunt and unpredictable.  (We're literally
> overwriting a piece of the database file that the process has open and
> has random parts in cache.)  I'm thinking this is not worth testing.

Does the attached look OK?

Thanks,

Mark

[-- Attachment #2: 0001-tests-Don-t-try-to-corrupt-sqlite-database-during-te.patch --]
[-- Type: text/x-patch, Size: 2973 bytes --]

From 46e4d78de4a51b6e7ea2a2dba150ac9599c29c2f Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Thu, 14 Apr 2022 13:26:57 +0200
Subject: [PATCH] tests: Don't try to corrupt sqlite database during test.

In run-debuginfod-federation-sqlite.sh we used to try to corrupt
the sqlite database while the debuginfod server was running and
check it detected errors, but that was unreliably and slightly
dangerous since part of the database was already mapped into memory.
Instead trigger some some random activity, then trigger a shutdown.

Signed-off-by: Mark Wielaard <mark@klomp.org>
---
 tests/ChangeLog                           |  5 +++++
 tests/run-debuginfod-federation-sqlite.sh | 17 +++++++++--------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/tests/ChangeLog b/tests/ChangeLog
index 6cb0d649..e49bff05 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,8 @@
+2022-04-14  Mark Wielaard  <mark@klomp.org>
+
+	* run-debuginfod-federation-sqlite.sh: Don't try to corrupt
+	sqlite database.
+
 2022-04-13  Aaron Merey  <amerey@redhat.com>
 
 	* Makefile.am (TESTS): Remove run-debuginfod-000-permission.sh
diff --git a/tests/run-debuginfod-federation-sqlite.sh b/tests/run-debuginfod-federation-sqlite.sh
index bb3cda12..d9321526 100755
--- a/tests/run-debuginfod-federation-sqlite.sh
+++ b/tests/run-debuginfod-federation-sqlite.sh
@@ -167,11 +167,11 @@ curl -s http://127.0.0.1:$PORT1/metrics | grep 'http_responses_after_you.*'
 # waiting.  A few hundred ms is typical on this developer's workstation.
 
 ########################################################################
-# Corrupt the sqlite database and get debuginfod to trip across its errors
-curl -s http://127.0.0.1:$PORT1/metrics | grep 'sqlite3.*reset'
-dd if=/dev/zero of=$DB bs=1 count=1
-
-# trigger some random activity that's Sure to get sqlite3 upset
+# Trigger some some random activity, then trigger a clean shutdown.
+# We used to try to corrupt the database while the debuginfod server
+# was running and check it detected errors, but that was unreliably
+# and slightly dangerous since part of the database was already mapped
+# into memory.
 kill -USR1 $PID1
 wait_ready $PORT1 'thread_work_total{role="traverse"}' 2
 wait_ready $PORT1 'thread_work_pending{role="scan"}' 0
@@ -179,14 +179,15 @@ wait_ready $PORT1 'thread_busy{role="scan"}' 0
 kill -USR2 $PID1
 wait_ready $PORT1 'thread_work_total{role="groom"}' 2
 curl -s http://127.0.0.1:$PORT1/buildid/beefbeefbeefd00dd00d/debuginfo > /dev/null || true
-curl -s http://127.0.0.1:$PORT1/metrics | grep 'error_count.*sqlite'
-# Run the tests again without the servers running. The target file should
-# be found in the cache.
 
 kill -INT $PID1 $PID2
 wait $PID1 $PID2
 PID1=0
 PID2=0
+
+# Run the tests again without the servers running. The target file should
+# be found in the cache.
+
 tempfiles .debuginfod_*
 
 testrun ${abs_builddir}/debuginfod_build_id_find -e F/prog 1
-- 
2.18.4


      reply	other threads:[~2022-04-14 11:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 17:21 buildbot
2022-04-13 18:51 ` Mark Wielaard
2022-04-13 19:09   ` Frank Ch. Eigler
2022-04-14 11:30     ` Mark Wielaard [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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c73b4e9a13d337fc61fa4c0e94ca36d3737a5084.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@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).