[PATCH OB] debuginfod-client.c: Skip empty file creation for cancelled queries
Committing as obvious.
Empty files in the client cache are used to indicate that contacted
servers could not find a requested resource. Future queries for this
resource will not be attempted until the cache_miss_s duration has
passed.
Currently these empty files are also created when a query is cancelled
through the client's progressfn. This can occur, for example, when a
user cancels a download with ctrl-c.
This prevents user-cancelled queries from being retried promptly without
having to modify cache_miss_s. Fix this by skipping the creation of an
empty cache file when progressfn cancels a query.
Signed-off-by: Aaron Merey
---
debuginfod/ChangeLog | 5 +
debuginfod/debuginfod-client.c | 6 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index f861eb72..5db5a753 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2023-03-17 Aaron Merey
+
+ * debuginfod-client.c (debuginfod_query_server): Do not create an
+ empty file in the cache if the query was cancelled by the progressfn.
+
2023-02-07 Aaron Merey
* debuginfod-client.c (cache_find_section): Avoid returning -ENOENT
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index ef4d47e3..b33408eb 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1667,9 +1667,9 @@ debuginfod_query_server (debuginfod_client *c,
}
} while (num_msg > 0);
- /* Create an empty file named as $HOME/.cache if the query fails
- with ENOENT.*/
- if (rc == -ENOENT)
+ /* Create an empty file in the cache if the query fails with ENOENT and
+ it wasn't cancelled early. */
+ if (rc == -ENOENT && !c->progressfn_cancel)
{
int efd = open (target_cache_path, O_CREAT|O_EXCL, DEFFILEMODE);
if (efd >= 0)
--
2.39.2
[Bug debuginfod/30221] Negative cache should differentiate failure types
https://sourceware.org/bugzilla/show_bug.cgi?id=30221 Aaron Merey changed: What|Removed |Added CC||amerey at redhat dot com --- Comment #9 from Aaron Merey --- (In reply to Vicki Pfau from comment #7) > I did, and in comment 2 I already explained why I think it's a bad idea.(In > reply to Frank Ch. Eigler from comment #6) > > (In reply to Vicki Pfau from comment #2) > > > 404 and the like *may* be transient, but the fact of the matter is that > > > *most* of the time it won't be And it's a cache, not a definitive answer > > > saying this will never exist. Having a 404 cache for 10x the amount of > > > time > > > as a Ctrl-C > > > > I don't understand - a ctrl-C should not result in a cached artifact at all. > > If that's happening, we should fix that. > > Okay, that is kinda weird then. I'm seeing it in gdb--perhaps it's a gdb > issue then. The issue was in libdebuginfod itself. I merged a fix for this: https://sourceware.org/pipermail/elfutils-devel/2023q1/006050.html > > > I'm already dealing with gdb taking well > > > over 30 seconds to start running a program with a bunch of shared object > > > dependencies that aren't in debuginfod... > > > > Uncached misses from debuginfod tend to take on the order of milliseconds, > > much less than seconds. Do you have a trace of what's happening? > > (DEBUGINFOD_VERBOSE=1 or something like that?) > > The issue appears to be the debuginfod server taking a not-insignificant > amount of time per request (500ms - 2s I'd estimate) to report the absence > of an associated artifact. Perhaps this is just an issue with how the server > is configured. I'm using the elfutils server, but I've seen the same issue > on Arch's server (the distro I'm using). It's worth noting too that some > users will undoubtedly have higher latency. A way to asynchronously initiate > requests so you can have multiple going at once would be great to try and > alleviate this somewhat, but it doesn't look like there's a way to do this > yet. There has been some discussion about gdb downloading from debuginfod in background worker threads. I would like to get this feature added eventually. -- You are receiving this mail because: You are on the CC list for the bug.
☺ Buildbot (Sourceware): elfutils - build successful (master)
A restored build has been detected on builder elfutils-opensusetw-x86_64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/88/builds/139 Build state: build successful Revision: 5527216460c6131527c27b06dada015b67525966 Worker: bb2-2 Build Reason: (unknown) Blamelist: Aaron Merey , Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/7/logs/test-suite_log - 8: make distcheck ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/8/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/8/logs/test-suite_log - warnings (5): https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/8/logs/warnings__5_ - 9: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/9/logs/stdio - 10: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/10/logs/stdio - 11: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/11/logs/stdio - 12: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/12/logs/stdio - 13: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/13/logs/stdio - 14: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/14/logs/stdio - 15: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/15/logs/stdio - 16: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/16/logs/stdio - 17: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/17/logs/stdio - 18: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/18/logs/stdio - 19: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/88/builds/139/steps/19/logs/stdio A retry build has been detected on builder elfutils-fedora-arm64 while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/180/builds/128 Build state: retry lost connection test (retry) Revision: 5527216460c6131527c27b06dada015b67525966 Worker: fedora-arm64 Build Reason: (unknown) Blamelist: Aaron Merey Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/180/builds/128/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/180/builds/128/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/180/builds/128/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/180/builds/128/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/180/builds/128/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/180/builds
[Bug debuginfod/30221] Negative cache should differentiate failure types
https://sourceware.org/bugzilla/show_bug.cgi?id=30221 --- Comment #10 from Aaron Merey --- (In reply to Vicki Pfau from comment #7) > The issue appears to be the debuginfod server taking a not-insignificant > amount of time per request (500ms - 2s I'd estimate) to report the absence > of an associated artifact. Long-lived TCP connections to debuginfod servers were added to GDB 11.1. Before that we'd set up and tear down a connection for each query which added unnecessary latency. So if you are using an older version of GDB this could explain some of the delay. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30241] New: RFE add APIs to elfutis libdw
https://sourceware.org/bugzilla/show_bug.cgi?id=30241 Bug ID: 30241 Summary: RFE add APIs to elfutis libdw Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Please add new APIs to write DWARF. Some of the users could be dwz and dyninst. One example would be: https://github.com/dyninst/dyninst/issues/1401#issuecomment-1473826160 where the problem is you relocate a function to instrument it but then the DWARF backtraces are then wrong. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/30241] RFE add APIs to elfutis libdw
https://sourceware.org/bugzilla/show_bug.cgi?id=30241 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- This depends largely on what sort of editing API a client envisions. Writing brand new content from scratch is more like an assembler task. Making micro edits in situ (changing individual DIEs, insert/delete, like a text editor) is likely to be entirely different and much more complicated. So ISTM this needs to be drive not by elfutils in the abstract but the specific needs of the editing/synthesis tools. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30221] Negative cache should differentiate failure types
https://sourceware.org/bugzilla/show_bug.cgi?id=30221 --- Comment #11 from Vicki Pfau --- I am using 11.1, but I think part of the problem is that Arch adopted debuginfod relatively recently and hasn't backfilled packages. I updated my packages yesterday and it took forever to start gdb today, but I think it was actually downloading most of those packages so it shouldn't leave negative cache this time. I don't know how debuginfod federation works either, but I'd absolutely believe that Arch's server is just slow for one reason or another, and somehow that's causing issues even though I'm querying the sourceware one directly. When I updated gdb a few days ago I did notice that the way information was presented to the user changed, and it did seem faster, but I'm unsure if that was just placebo effect due to the fact that it was telling me more information now. -- You are receiving this mail because: You are on the CC list for the bug.
