[Bug general/29082] Support GNU_PROPERTY_TYPE_0 in eu-readelf -n
https://sourceware.org/bugzilla/show_bug.cgi?id=29082 Martin Liska changed: What|Removed |Added CC||fweimer at redhat dot com, ||hjl at sourceware dot org --- Comment #2 from Martin Liska --- (In reply to Mark Wielaard from comment #1) > Do you have a spec for that? Ccing Florian and H.J. who should know that. -- You are receiving this mail because: You are on the CC list for the bug.
Re: symbol resolution differences with -flto
On Freitag, 15. April 2022 14:09:02 CEST Milian Wolff wrote: > Hey there, > > a user reported broken symbol resolution in hotspot/perfparser which uses > elfutils when he's using it on code compiled with LTO. > > I think I can reproduce this, and now spent some time trying to figure out > the breakage. I found at least one situation that is seemingly related to > the user's issue. Below are some observation of mine and then some > questions, as I cannot explain this situation and hope that someone around > here has more knowledge on how to handle this correctly. To answer my own question: The issue arises for functions with debug information that are not exported. Those won't have an entry in the symbol table, but by looking at the dwarf information we can still assign them a scope name from the respective DIEs, just like one would do for inline frames too. Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
[Bug general/29082] Support GNU_PROPERTY_TYPE_0 in eu-readelf -n
https://sourceware.org/bugzilla/show_bug.cgi?id=29082 --- Comment #3 from H.J. Lu --- NT_GNU_PROPERTY_TYPE_0 is documented in https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf https://gitlab.com/x86-psABIs/x86-64-ABI/-/wikis/uploads/01de35b2c8adc7545de52604cc45d942/x86-64-psABI-2021-05-20.pdf -- You are receiving this mail because: You are on the CC list for the bug.
Re: PATCH: testsuite debuginfod
> Date: Sat, 16 Apr 2022 14:37:23 -0400 > Mark Wielaard writes: > > > I think we should drop this patch for now. Or are you still working on > > it? > > Sure, let's drop it. > Will bring in the xfail "cmd..." based one instead before too long. > > - FChE - FChE
[PATCH] debuginfod, libdwfl: Initialize libcurl and dlopen debuginfod-client lazily
We used to go out of our way to initialize libcurl early before any other
thread/code was running. But this meant that we might pay startup cost,
which under FIPS is significant, even for code that never uses libdebuginfod
or TLS libcurl connections. Although curl_global_init itself isn't thread-safe
we can use pthread_once to make sure we don't race against ourselves. This
still means we might race against any application code that might use
libcurl. But we can assume they will have called curl_global_init before
calling dwfl_begin or debuginfod_begin.
Signed-off-by: Mark Wielaard
---
debuginfod/ChangeLog | 10 ++
debuginfod/Makefile.am | 4 ++--
debuginfod/debuginfod-client.c | 29 ++---
libdwfl/ChangeLog | 7 +++
libdwfl/debuginfod-client.c| 14 +++---
5 files changed, 44 insertions(+), 20 deletions(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index d6f7b282..7d790bf9 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,13 @@
+2022-04-22 Mark Wielaard
+
+ * Makefile.am (libdebuginfod): Add -lpthread.
+ (libdebuginfod_so_LDLIBS): Likewise.
+ * debuginfod-client.c (init_control): New static pthread_once_t.
+ (libcurl_init): New static function.
+ (debuginfod_begin): Use ptrace_once to call libcurl_init.
+ (libdebuginfod_ctor): Removed.
+ (libdebuginfod_dtor): Likewise.
+
2022-04-13 Aaron Merey
* debuginfod-client.c (debuginfod_query_server):
diff --git a/debuginfod/Makefile.am b/debuginfod/Makefile.am
index 3adb2755..435cb8a6 100644
--- a/debuginfod/Makefile.am
+++ b/debuginfod/Makefile.am
@@ -47,7 +47,7 @@ libelf = ../libelf/libelf.a -lz
if DUMMY_LIBDEBUGINFOD
libdebuginfod = ./libdebuginfod.a
else
-libdebuginfod = ./libdebuginfod.a $(libcurl_LIBS)
+libdebuginfod = ./libdebuginfod.a -lpthread $(libcurl_LIBS)
endif
else
libasm = ../libasm/libasm.so
@@ -97,7 +97,7 @@ libdebuginfod_so_LIBS = libdebuginfod_pic.a
if DUMMY_LIBDEBUGINFOD
libdebuginfod_so_LDLIBS =
else
-libdebuginfod_so_LDLIBS = $(libcurl_LIBS) $(fts_LIBS)
+libdebuginfod_so_LDLIBS = -lpthread $(libcurl_LIBS) $(fts_LIBS)
endif
$(LIBDEBUGINFOD_SONAME): $(srcdir)/libdebuginfod.map $(libdebuginfod_so_LIBS)
$(AM_V_CCLD)$(LINK) $(dso_LDFLAGS) -o $@ \
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 58ef6442..45a27b5e 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1,6 +1,6 @@
/* Retrieve ELF / DWARF / source files from the debuginfod.
Copyright (C) 2019-2021 Red Hat, Inc.
- Copyright (C) 2021 Mark J. Wielaard
+ Copyright (C) 2021, 2022 Mark J. Wielaard
This file is part of elfutils.
This file is free software; you can redistribute it and/or modify
@@ -98,6 +98,16 @@ void debuginfod_end (debuginfod_client *c) { }
#include
#endif
+#include
+
+static pthread_once_t init_control = PTHREAD_ONCE_INIT;
+
+static void
+libcurl_init(void)
+{
+ curl_global_init(CURL_GLOBAL_DEFAULT);
+}
+
struct debuginfod_client
{
/* Progress/interrupt callback function. */
@@ -1475,6 +1485,9 @@ debuginfod_query_server (debuginfod_client *c,
debuginfod_client *
debuginfod_begin (void)
{
+ /* Initialize libcurl lazily, but only once. */
+ pthread_once (&init_control, libcurl_init);
+
debuginfod_client *client;
size_t size = sizeof (struct debuginfod_client);
client = calloc (1, size);
@@ -1608,18 +1621,4 @@ debuginfod_set_verbose_fd(debuginfod_client *client, int
fd)
client->verbose_fd = fd;
}
-
-/* NB: these are thread-unsafe. */
-__attribute__((constructor)) attribute_hidden void libdebuginfod_ctor(void)
-{
- curl_global_init(CURL_GLOBAL_DEFAULT);
-}
-
-/* NB: this is very thread-unsafe: it breaks other threads that are still in
libcurl */
-__attribute__((destructor)) attribute_hidden void libdebuginfod_dtor(void)
-{
- /* ... so don't do this: */
- /* curl_global_cleanup(); */
-}
-
#endif /* DUMMY_LIBDEBUGINFOD */
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 9c5c8517..76053039 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,10 @@
+2022-04-22 Mark Wielaard
+
+ * debuginfod-client.c (init_control): New static pthread_once_t.
+ (get_client): Use pthread_once to call __libdwfl_debuginfod_init.
+ (__libdwfl_debuginfod_init): Make static, remove attribute
+ constructor.
+
2022-02-18 Mark Wielaard
* image-header.c (__libdw_image_header): Assign header values for
diff --git a/libdwfl/debuginfod-client.c b/libdwfl/debuginfod-client.c
index 99b66b6e..153260c3 100644
--- a/libdwfl/debuginfod-client.c
+++ b/libdwfl/debuginfod-client.c
@@ -1,5 +1,6 @@
/* Try to get an ELF or debug file through the debuginfod.
Copyright (C) 2019 Red Hat, Inc.
+ Copyright (C) 2022 Mark J. Wielaard
This file is part of elfutils.
This file is free software; you can redistribute it and/or modify
@@
Re: Using libcurl in another library, when/if to call curl_global_init?
Hi, On Thu, Mar 31, 2022 at 03:19:51PM +0200, Mark Wielaard via curl-library wrote: > On Thu, Mar 31, 2022 at 04:00:16PM +0300, Catalin Raceanu via curl-library > wrote: > > On 31-Mar-22 15:04, Mark Wielaard wrote: > > > whether there is a thread-safe way to call > > > curl_global_init at a later time (to get rid of the library constructor > > > init function). > > > > I believe that this is an exact fit for C==11's std::call_once(). Boost also > > has an equivalent, that most likely predates the other, in case older c++ > > standard is used. > > Thanks. Our library is pure C, but we can probably rely on > pthread_once if it is allowable to call curl_global_init at a later > time when multiple threads are already running. The reason we aren't > doing that now is because the curl_global_init documentation > explicitly states "You must not call it when any other thread in the > program is running". But maybe we are interpreting the documentation > too strictly? Since it does seem we were interpreting the documentation a bit too strictly I did propose a patch for elfutils that does lazy initialization using pthread_once. https://sourceware.org/pipermail/elfutils-devel/2022q2/004934.html This makes sure we don't race against ourselves. And for programs using our library we can assume they will call curl_global_init before creating a multi-threaded environment and calling our own handle initialization functions. It would still be great if curl_global_init itself could be made thread-safe to call. Thanks, Mark
[PATCH 2/2] debuginfod: ensure X-DEBUGINFOD-SIZE contains file size
For archived files X-DEBUGINFOD-SIZE currently contains the size of the
archive instead of the size of the uncompressed file. Fix this.
Also add testcases to verify X-DEBUGINFOD-SIZE contains uncompressed
file sizes.
Signed-off-by: Aaron Merey
---
debuginfod/debuginfod.cxx| 11 +--
tests/run-debuginfod-response-headers.sh | 8
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
index 9c0217f6..d61757ae 100644
--- a/debuginfod/debuginfod.cxx
+++ b/debuginfod/debuginfod.cxx
@@ -1789,11 +1789,18 @@ handle_buildid_r_match (bool internal_req_p,
std::string file = b_source1.substr(b_source1.find_last_of("/")+1,
b_source1.length());
add_mhd_response_header (r, "Content-Type",
"application/octet-stream");
- add_mhd_response_header (r, "X-DEBUGINFOD-SIZE",
- to_string(fs.st_size).c_str());
add_mhd_response_header (r, "X-DEBUGINFOD-ARCHIVE",
b_source0.c_str());
add_mhd_response_header (r, "X-DEBUGINFOD-FILE", file.c_str());
+ rc = fstat (fd, &fs);
+ if (rc == 0)
+add_mhd_response_header (r, "X-DEBUGINFOD-SIZE",
+ to_string(fs.st_size).c_str());
+ else
+{
+ close (fd);
+ throw libc_exception (errno, string("stat ") + b_source1 + "
archive " + b_source0);
+}
add_mhd_last_modified (r, archive_entry_mtime(e));
if (verbose > 1)
obatched(clog) << "serving archive " << b_source0 << " file " <<
b_source1 << endl;
diff --git a/tests/run-debuginfod-response-headers.sh
b/tests/run-debuginfod-response-headers.sh
index 10b2ab49..62c43887 100755
--- a/tests/run-debuginfod-response-headers.sh
+++ b/tests/run-debuginfod-response-headers.sh
@@ -86,6 +86,14 @@ grep 'X-DEBUGINFOD-FILE: ' vlog-find$PORT1.2
grep 'X-DEBUGINFOD-SIZE: ' vlog-find$PORT1.2
grep 'X-DEBUGINFOD-ARCHIVE: ' vlog-find$PORT1.2
+# Check that X-DEBUGINFOD-SIZE matches the size of each file
+for file in vlog-find$PORT1.1 vlog-find$PORT1.2
+do
+st_size=$(stat -c%s $(tail -n 1 $file))
+x_debuginfod_size=$(grep 'X-DEBUGINFOD-SIZE' $file | egrep -o '[0-9]+')
+test $st_size -eq $x_debuginfod_size
+done
+
kill $PID1
wait $PID1
PID1=0
--
2.35.1
Re: [PATCH 2/2] debuginfod: ensure X-DEBUGINFOD-SIZE contains file size
Please ignore the "2/2" in the subject line, this patch is not part of a series. Aaron
Re: [PATCH] debuginfod: Use the debuginfod-size response header
I've updated the patch below with the changes Mark recommended.
A couple X-DEBUGINFOD-SIZE tests were added in another patch I recently
posted [1] that also fixes a bug when computing this header's value for
an archived file.
Aaron
[1] https://sourceware.org/pipermail/elfutils-devel/2022q2/004936.html
>From b56f1568b832fe1c23ffb711aa0486fbd2c5067f Mon Sep 17 00:00:00 2001
From: Aaron Merey
Date: Tue, 11 Jan 2022 22:07:55 -0500
debuginfod: Use the debuginfod-size response header
In some cases the content-length header may not be available in order
to pass to a progressfn. If content-length isn't available then attempt
to get the size of the download from the debuginfod-size header instead.
It should be mentioned that if a compressed file (ex. gzip) is being
transferred, the actual transfer length will be less than debuginfod-size.
In this case debuginfod-size is a best-guess upper bound on the size of
the transfer.
Signed-off-by: Aaron Merey
---
debuginfod/debuginfod-client.c | 83 ++
1 file changed, 43 insertions(+), 40 deletions(-)
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 58ef6442..de7ea1af 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1130,11 +1130,45 @@ debuginfod_query_server (debuginfod_client *c,
goto out2;
}
+ long dl_size = 0;
+ if (target_handle && (c->progressfn || maxsize > 0))
+{
+ /* Get size of file being downloaded. NB: If going through
+ deflate-compressing proxies, this number is likely to be
+ unavailable, so -1 may show. */
+ CURLcode curl_res;
+#ifdef CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
+ curl_off_t cl;
+ curl_res = curl_easy_getinfo(target_handle,
+ CURLINFO_CONTENT_LENGTH_DOWNLOAD_T,
+ &cl);
+ if (curl_res == CURLE_OK && cl >= 0)
+dl_size = (cl > LONG_MAX ? LONG_MAX : (long)cl);
+#else
+ double cl;
+ curl_res = curl_easy_getinfo(target_handle,
+ CURLINFO_CONTENT_LENGTH_DOWNLOAD,
+ &cl);
+ if (curl_res == CURLE_OK)
+dl_size = (cl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)cl);
+#endif
+ /* If Content-Length is -1, try to get the size from
+ X-Debuginfod-Size */
+ if (dl_size == -1 && c->winning_headers != NULL)
+{
+ long xdl;
+ char *hdr = strcasestr(c->winning_headers, "x-debuginfod-size");
+
+ if (hdr != NULL
+ && sscanf(hdr, "x-debuginfod-size: %ld", &xdl) == 1)
+dl_size = xdl;
+}
+}
+
if (c->progressfn) /* inform/check progress callback */
{
loops ++;
- long pa = loops; /* default params for progress callback */
- long pb = 0; /* transfer_timeout tempting, but loops != elapsed-time
*/
+ long pa = loops; /* default param for progress callback */
if (target_handle) /* we've committed to a server; report its
download progress */
{
CURLcode curl_res;
@@ -1154,50 +1188,19 @@ debuginfod_query_server (debuginfod_client *c,
pa = (dl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)dl);
#endif
- /* NB: If going through deflate-compressing proxies, this
- number is likely to be unavailable, so -1 may show. */
-#ifdef CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
- curl_off_t cl;
- curl_res = curl_easy_getinfo(target_handle,
- CURLINFO_CONTENT_LENGTH_DOWNLOAD_T,
- &cl);
- if (curl_res == 0 && cl >= 0)
-pb = (cl > LONG_MAX ? LONG_MAX : (long)cl);
-#else
- double cl;
- curl_res = curl_easy_getinfo(target_handle,
- CURLINFO_CONTENT_LENGTH_DOWNLOAD,
- &cl);
- if (curl_res == 0)
-pb = (cl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)cl);
-#endif
}
- if ((*c->progressfn) (c, pa, pb))
+ if ((*c->progressfn) (c, pa, dl_size))
break;
}
+
/* Check to see if we are downloading something which exceeds maxsize,
if set.*/
- if (maxsize > 0 && target_handle)
+ if (target_handle && dl_size > maxsize && maxsize > 0)
{
- long dl_size = 0;
-#ifdef CURLINFO_SIZE_DOWNLOAD_T
- curl_off_t download_size_t;
- if (curl_easy_getinfo(target_handle,
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T,
-&download_size_t) ==
CURLE_OK)
-dl_size = download_size_t >= (double)(LONG_MAX+1UL) ? LONG_MAX :
(long
Re: [PATCH 2/2] debuginfod: ensure X-DEBUGINFOD-SIZE contains file size
Hi -
> - add_mhd_response_header (r, "X-DEBUGINFOD-SIZE",
> - to_string(fs.st_size).c_str());
> + rc = fstat (fd, &fs);
> + if (rc == 0)
> +add_mhd_response_header (r, "X-DEBUGINFOD-SIZE",
> + to_string(fs.st_size).c_str());
> + else
> +{
> + close (fd);
> + throw libc_exception (errno, string("stat ") + b_source1 + "
> archive " + b_source0);
> +}
It shouldn't require a new fstat -- the archive component file's size
should be available from libarchive already: archive_entry_size(e);
- FChE
Re: [PATCH v2] config: simplify profile.*sh.in
Hi наб, On Fri, Apr 15, 2022 at 02:12:31PM +0200, наб via Elfutils-devel wrote: > On Fri, Apr 15, 2022 at 01:48:23PM +0200, Mark Wielaard wrote: > > I have added a ChangeLog entry: > > > > 2022-01-19 Ahelenia Ziemiańska > > > >* profile.csh.in: Set DEBUGINFOD_URLS directly. Use "$0" and : > >in sh -c. > >* profile.sh.in: Set DEBUGINFOD_URLS directly. Don't use sh -c. > >Use $() instead of ``. > > > > Full commit at: > > https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=simplify-profile > > Yeah, that looks about right. > > > Ahelenia, under which shells have you tested this? > csh, dash, and bash, whichever versions were current in sid x32 > when I posted this (not that it matters much, I think, > the sh version is specified by POSIX, and csh is unchanging). Thanks, pushed now, Mark
☠ Buildbot (GNU Toolchain): elfutils - failed test (failure) (master)
A new failure has been detected on builder elfutils-debian-ppc64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/63/builds/4 Build state: failed test (failure) Revision: 7b046b7c060acc32c00748ee66ac350f77bc6571 Worker: debian-ppc64 Build Reason: (unknown) Blamelist: наб via Elfutils-devel Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/6/logs/warnings__3_ - 7: make check ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/7/logs/test-suite_log
☺ Buildbot (GNU Toolchain): elfutils - build successful (master)
A restored build has been detected on builder elfutils-fedora-x86_64 while building elfutils. Full details are available at: http://localhost:8010/#builders/30/builds/19 Build state: build successful Revision: aaa875db4d6dfa410903a08235a3c6cdc13842e5 Worker: fedora-x86_64 Build Reason: (unknown) Blamelist: Aaron Merey , Di Chen , Frank Ch. Eigler , Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/4/logs/stdio - 5: get version ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/5/logs/stdio - property changes: http://localhost:8010/#builders/30/builds/19/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/6/logs/stdio - warnings (3): http://localhost:8010/#builders/30/builds/19/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/7/logs/stdio - test-suite.log: http://localhost:8010/#builders/30/builds/19/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/8/logs/stdio - 9: fetch log files from worker ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/9/logs/stdio - 10: pass .bunsen.source.gitname ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/10/logs/stdio - 11: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/11/logs/stdio - 12: upload to bunsen ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/12/logs/stdio - 13: clean up ( success ) Logs: - stdio: http://localhost:8010/#builders/30/builds/19/steps/13/logs/stdio
Re: ☠ Buildbot (GNU Toolchain): elfutils - failed test (failure) (master)
On Sat, Apr 23, 2022 at 01:19:53AM +, builder--- via Elfutils-devel wrote:
> A new failure has been detected on builder elfutils-debian-ppc64 while
> building elfutils.
>
> Full details are available at:
> https://builder.sourceware.org/buildbot/#builders/63/builds/4
>
> Build state: failed test (failure)
> Revision: 7b046b7c060acc32c00748ee66ac350f77bc6571
> Worker: debian-ppc64
> Build Reason: (unknown)
> Blamelist: наб via Elfutils-devel
>
> Steps:
> [...]
> - 7: make check ( failure )
> Logs:
> - stdio:
> https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/7/logs/stdio
> - test-suite.log:
> https://builder.sourceware.org/buildbot/#builders/63/builds/4/steps/7/logs/test-suite_log
Gah. It is run-debuginfod-webapi-concurrency.sh again with
error_count{libmicrohttpd="Server reached connection limit.
Closing inbound connection.\n"} 9
I guess 100 parallel lookups really is too much. I am going to lower
it to 64.
Cheers,
Mark>From 318807e7f968fd70b80408e3df029c04365c47d8 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Sat, 23 Apr 2022 03:20:17 +0200
Subject: [PATCH] tests: Lower parallel lookups in
run-debuginfod-webapi-concurrency.sh
With 100 parallel lookups we sometimes see:
Server reached connection limit. Closing inbound connection.
Lower parallel lookups to 64
Signed-off-by: Mark Wielaard
---
tests/ChangeLog| 4
tests/run-debuginfod-webapi-concurrency.sh | 7 ---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index c734b260..2286f53f 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,7 @@
+2022-04-23 Mark Wielaard
+
+ * run-debuginfod-webapi-concurrency.sh: Lower parallel lookups.
+
2022-03-01 Di Chen
* alldts.c (dtflags): Put DT_NULL last.
diff --git a/tests/run-debuginfod-webapi-concurrency.sh b/tests/run-debuginfod-webapi-concurrency.sh
index 402a6307..4928f6d0 100755
--- a/tests/run-debuginfod-webapi-concurrency.sh
+++ b/tests/run-debuginfod-webapi-concurrency.sh
@@ -47,12 +47,13 @@ do
wait_ready $PORT1 'thread_busy{role="scan"}' 0
# Do a bunch of lookups in parallel
-for jobs in `seq 100`; do
+lookup_nr=64
+for jobs in `seq $lookup_nr`; do
curl -s http://localhost:$PORT1/buildid/cee13b2ea505a7f37bd20d271c6bc7e5f8d2dfcb/debuginfo > /dev/null &
done
-# all 100 curls should succeed
-wait_ready $PORT1 'http_responses_transfer_bytes_count{code="200",type="debuginfo"}' 100
+# all curls should succeed
+wait_ready $PORT1 'http_responses_transfer_bytes_count{code="200",type="debuginfo"}' $lookup_nr
(sleep 5;
curl -s http://localhost:$PORT1/metrics | egrep 'error|responses';
--
2.30.2
