[Bug debuginfod/30879] intermittent failure (libstdc++ uncaught exception terminate) during testsuite on sparc-gentoo
https://sourceware.org/bugzilla/show_bug.cgi?id=30879 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- Author: Frank Ch. Eigler Date: Fri Sep 22 15:30:51 2023 -0400 PR30879: intermittent debuginfod crash with unhandled exception -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30962] New: ensure x-debuginfod-file / -archive headers always return full path names
https://sourceware.org/bugzilla/show_bug.cgi?id=30962 Bug ID: 30962 Summary: ensure x-debuginfod-file / -archive headers always return full path names Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- We kind of decided haphazardly to `basename` some of those strings and not others. This was partly with some halfbaked notion of security in mind, to avoid exposing path names on a server. We should switch to full path names: basically just return everything in its raw form: file names, archive names, names-from-archives. This would simplify things, and making naming consistent between x-debuginfod-file: BASENAME and the forthcoming metadata-query FULLPATH. And we can document how to strip sensitive prefixes if admins want to keep things hush-hush. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30962] ensure x-debuginfod-file / -archive headers always return full path names
https://sourceware.org/bugzilla/show_bug.cgi?id=30962 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- Author: Frank Ch. Eigler Date: Tue Oct 10 16:21:00 2023 -0400 PR30962: debuginfod: full paths for X-DEBUGINFOD-FILE/ARCHIVE response headers -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- Note that elfutils has impending patches (awaiting final review) for relaying and verifying RPM-IMA per-file crypto signatures: bug #28204. Fedora has been shipping these types of signatures since something like f37 or f38. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30978 --- Comment #4 from Frank Ch. Eigler --- Note that the main problem with this sort of scheme is not the checksum (whether CRC or a hash). That part can help provide some assurance against accidental corruption. (Plus you'd need external checksums for source files, which can't get additional ELF doohickeys inserted. But you'd need crypto signatures on those hashes in order to protect against deliberate corruption anywhere between the original build system and your client. That in turn requires distribution of crypto keys. It goes well beyond the objcopy stuff. I'm not sure whether the debian ecosystem has started thinking about this stuff, but when/if they do, debuginfod should be adaptable to pass on whatever assurances are possible. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #3 from Frank Ch. Eigler --- Is there some reason not to just bump up that bitfield width from :24 to :32 or more for now, until a deeper analysis of llvm informs us as to how wide these discriminator codes can really be? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 --- Comment #7 from Frank Ch. Eigler --- > So my preferred workaround: appears to be based on the assumption that truncated bitfields will not collide. Has this assumption been tested? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #8 from Frank Ch. Eigler ---
> The issue here is that we create (very) large arrays of struct Dwarf_Line_s
> and we do that eagerly, see bug #27405
> So we would like to keep that struct as small as possible.
Do we have an estimate about the numbers we're talking about here? The current
Dwarf_Line_s object is 40 bytes long (on x86-64). Even if packing becomes less
efficient, it could cost us say 2 bytes more per record. These records are
packed together in allocation via realloc() et al. How many records do we see
in programs of interest? readelf -wL /bin/emacs indicates about 800 thousand;
libxul.so about 8 million. Is this about single digit megabytes more RAM in
grand total?
Note that bug #27405 was a request for optimization, not in order to save a few
percent of memory for used data, but to save ALL the related memory & time for
totally unused data.
struct Dwarf_Line_s {
Dwarf_Files * files;/* 0 8 */
Dwarf_Addr addr; /* 8 8 */
unsigned int file; /*16 4 */
intline; /*20 4 */
short unsigned int column; /*24 2 */
/* Bitfield combined with previous fields */
unsigned int is_stmt:1;/*24:16 4 */
unsigned int basic_block:1;/*24:17 4 */
unsigned int end_sequence:1; /*24:18 4 */
unsigned int prologue_end:1; /*24:19 4 */
unsigned int epilogue_begin:1; /*24:20 4 */
unsigned int op_index:8; /*24:21 4 */
/* XXX 3 bits hole, try to pack */
/* Force alignment to the next boundary: */
unsigned int :0;
unsigned int isa:8;/*28: 0 4 */
unsigned int discriminator:24; /*28: 8 4 */
unsigned int context; /*32 4 */
unsigned int function_name;/*36 4 */
/* size: 40, cachelines: 1, members: 15 */
/* sum members: 34 */
/* sum bitfield members: 45 bits, bit holes: 1, sum bit holes: 3 bits
*/
/* last cacheline: 40 bytes */
};
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 --- Comment #11 from Frank Ch. Eigler --- > I'm more interested in this: what is worst that can happen on discriminator > collision? We are not using discriminator at all in ABI monitoring, so I'm > not familiar with its use cases. That's a good point. There is an api call dwarf_linediscriminator() to fetch it for a client. In a bit of searching here and there (github etc.), I have not found any user so far, other than readelf itself to print. In gnu binutils, the field is "unsigned int" wide, and is used in bfd & gdb. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] New: periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 Bug ID: 31103 Summary: periodically malloc_trim() Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- debuginfod's memory usage can fluctuate widely during the scan & groom phases. In the same places where we call sqlite3_db_release_memory() - and maybe more of the same - we should subsequently call malloc_trim(). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31248] New: debuginfod_find_* may return fd with file-offset at end
https://sourceware.org/bugzilla/show_bug.cgi?id=31248 Bug ID: 31248 Summary: debuginfod_find_* may return fd with file-offset at end Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- During the srcfiles test case diagnosis, studying the reason for occasional 0-length files, found something funky about the debuginfod_find_FOO api. It appears possible for first-time-downloaded files to result in FDs that were freshly written into by curl, with the file offset positioned right at the end. We should lseek(2) to the front. Clients would expect to be able to read it, as opposed to an insta-EOF. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31265] New: improve cache retention logic to prefer small / frequent / slow files
https://sourceware.org/bugzilla/show_bug.cgi?id=31265 Bug ID: 31265 Summary: improve cache retention logic to prefer small / frequent / slow files Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- In light of https://bugzilla.redhat.com/show_bug.cgi?id=1970578 still being open, we should probably tweak the server side caching to add a measure of cost/time to the retention logic. Ditch LRU, add some retention scoring that prefers to keep vdso.* stuff that takes 60s to extract, and yet is regularly requested. The resulting formula might need to be heuristic or statistical in nature. It should probably avoid retaining very slow/large but rare files (kernel images). It should probably favour -similar- files (vdso's from different package versions) even before usage counts. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27913] extend webapi for gdb-index queries
https://sourceware.org/bugzilla/show_bug.cgi?id=27913 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- previously completed client/server side work: commit fb833750c395ce268d16fd44e4decafbb41208a8 Author: Aaron Merey Date: Mon Oct 31 23:44:23 2022 -0400 debuginfod: Support queries for ELF/DWARF sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 --- Comment #2 from Frank Ch. Eigler --- Right, but the sqlite3* calls are still needed. I'm especially curious whether any impact from the malloc_trim() is measurable. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 --- Comment #5 from Frank Ch. Eigler --- Yeah, not surprised that there are no leaks. What this malloc_trim() and the preceding sqlite3_db_release_memory() calls are supposed to do is to release memory back to the operating system. So perhaps a getrusage() call in between could be informative. i.e.: struct rusage pre,during,post; getrusage(RUSAGE_SELF, &pre); sqlite3_db_release_memory( ...); getrusage(RUSAGE_SELF, &during); malloc_trim(); getrusage(RUSAGE_SELF, &post); and then the ru_idrss value should show some decrease ... except on linux, ru_idrss is not supplied by the kernel. So instead something like the VmSize or VmData fields in /proc/self/status, ugh? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 --- Comment #7 from Frank Ch. Eigler --- Right, the linux kernel does not share enough memory consumption data in rusage, so you need to read /proc/self/statm or such and compare its snapshots. For memory release, it's not so much the size of the database that matters, but an amount of -activity- on the database before the release attempt. It's the memory allocation for temporary purposes (answering queries, adding data to the database during scans) that we'd be hoping to release. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 --- Comment #9 from Frank Ch. Eigler --- Yeah, OK, for a not-too-busy one, that sounds okay. Can you show a proposed final diff? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31103] periodically malloc_trim()
https://sourceware.org/bugzilla/show_bug.cgi?id=31103 Frank Ch. Eigler changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Frank Ch. Eigler --- further malloc_trim()s may be investigated in other spots. PR31103: debuginfod: periodically call malloc_trim(0) Add malloc_trim() for releasing memory which is allocated for temporary purposes, e.g. answering queries, adding data to the database during scans. This patch just adds one call after the groom cycle, but others could be added around webapi query handling or scanning ops too. Signed-off-by: Di Chen (Sorry about committing with the wrong git-author!) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31620] debuginfod should not require ssl support from libcurl
https://sourceware.org/bugzilla/show_bug.cgi?id=31620 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- Okay, do you happen to know how debuginfod can find out whether libcurl supports https? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31620] debuginfod should not require ssl support from libcurl
https://sourceware.org/bugzilla/show_bug.cgi?id=31620 --- Comment #3 from Frank Ch. Eigler --- like this? can you test? diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c index 0ee7db3d6638..a3468f534656 100644 --- a/debuginfod/debuginfod-client.c +++ b/debuginfod/debuginfod-client.c @@ -1367,14 +1367,19 @@ debuginfod_query_server (debuginfod_client *c, } \ } while (0) + curl_version_info_data *d = curl_version_info(CURLVERSION_NOW); + /* Only allow http:// + https:// + file:// so we aren't being redirected to some unsupported protocol. */ #if CURL_AT_LEAST_VERSION(7, 85, 0) curl_easy_setopt_ck(data[i].handle, CURLOPT_PROTOCOLS_STR, - "http,https,file"); + ((d && d->ssl_version) ? + "http,https,file" : "http,file")); #else curl_easy_setopt_ck(data[i].handle, CURLOPT_PROTOCOLS, - (CURLPROTO_HTTP | CURLPROTO_HTTPS | CURLPROTO_FILE)); + (CURLPROTO_HTTP | + ((d && d->ssl_version) ? CURLPROTO_HTTPS : 0) | + CURLPROTO_FILE)); #endif curl_easy_setopt_ck(data[i].handle, CURLOPT_URL, data[i].url); if (vfd >= 0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31620] debuginfod should not require ssl support from libcurl
https://sourceware.org/bugzilla/show_bug.cgi?id=31620 --- Comment #6 from Frank Ch. Eigler --- Note that the "modern way" is not necessarily the desirable way. If the old way will keep working, I'd rather use that than a using a version-conditionalized query. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31637] segmentation fault when calling 'debuginfod-find -v'
https://sourceware.org/bugzilla/show_bug.cgi?id=31637 Frank Ch. Eigler changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- Fixed with commit d9f38a7052c22c7762aa5b98b401e8a324336bce, committed as obvious. diff --git a/debuginfod/debuginfod-find.c b/debuginfod/debuginfod-find.c index 307310988c4c..080dd8f2c6a3 100644 --- a/debuginfod/debuginfod-find.c +++ b/debuginfod/debuginfod-find.c @@ -136,7 +136,7 @@ main(int argc, char** argv) int remaining; (void) argp_parse (&argp, argc, argv, ARGP_IN_ORDER|ARGP_NO_ARGS, &remaining, NULL); - if (argc < 2 || remaining+1 == argc) /* no arguments or at least two non-option words */ + if (argc < 2 || remaining+1 >= argc) /* no arguments or at least two non-option words */ and a little test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31620] debuginfod should not require ssl support from libcurl
https://sourceware.org/bugzilla/show_bug.cgi?id=31620 --- Comment #9 from Frank Ch. Eigler --- This version looks okay to me too, FWIW, just a little bit more work. I'd appreciate a pointer to any curl documentation that suggests upcoming deprecation of the curl_version_info_data->ssl_version field. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/31729] New: the huge-file test is too sloooow
https://sourceware.org/bugzilla/show_bug.cgi?id=31729 Bug ID: 31729 Summary: the huge-file test is too slw Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- run-large-elf-file.sh does a little speed gating predicate before launching its 4GB I/O test, but it is IMO too optimistic. On my box, where the source/build trees are often NFS-mounted, the 100MB/s initial test passes, but the whole test takes O(minutes). It would be better if the the check plopped the test files onto something like /var/tmp, which is apprx. guaranteed to be local disk. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31842] New: add "permissive" mode for debuginfod signature verification
https://sourceware.org/bugzilla/show_bug.cgi?id=31842 Bug ID: 31842 Summary: add "permissive" mode for debuginfod signature verification Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Follow up on bug #28204 in hope of arriving at a mode that is a compelling default for distro builds of elfutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/31862] New: debuginfod client should cache received x-debuginfod-* headers
https://sourceware.org/bugzilla/show_bug.cgi?id=31862 Bug ID: 31862 Summary: debuginfod client should cache received x-debuginfod-* headers Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Caching alongside the payload would permit the client to repeat IMA checks later, and would permit federated / caching servers to pass back IMA (and other) headers to the ultimate client. This shouldn't require an api/webapi change. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/31866] --enable-libdebuginfod=dummy does not work
https://sourceware.org/bugzilla/show_bug.cgi?id=31866 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- Hi, Andreas, could you share your config.log ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/31944] New: RFE: dwfl_linux_proc_self_attach
https://sourceware.org/bugzilla/show_bug.cgi?id=31944 Bug ID: 31944 Summary: RFE: dwfl_linux_proc_self_attach Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Elfutils/dwfl operation startup can be costly, as elfutils loads and processes files on disk. In the case of a self-instrumenting program, one that just wishes to generate backtraces, some of that work may be saved. For example, instead of using ptrace for cross-process memory/register access, in self-attach mode, the library can just use direct work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32062] New: analyze eu-stacktrace w.r.t. debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=32062
Bug ID: 32062
Summary: analyze eu-stacktrace w.r.t. debuginfod
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: tools
Assignee: unassigned at sourceware dot org
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
May need debuginfod help in case of:
- lack of buildid-matching executable (for .eh_frame)
- lack of buildid-matching debuginfo (if .eh_frame is absent, so need
.debug_frame)
So for those cases, consider some mixture of:
- diagnostics: enumerate newly encountered buildids for reporting
- invoke debuginfod-find {executable,debuginfo} (which?) $buildid in background
- have eu-stacktrace NOT disable debuginfod fallback hooks
- check how much latency (downloading time) might be tolerable to
sysprof/consumers
- check how much RAM could be consumed by copying incoming stack-dump ring
buffer frames while waiting for debuginfo /etc. download
- check whether $DEBUGINFOD_MAXTIME is sufficient knob of control
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/32063] New: let debuginfod-find locate pre-installed (/usr/lib/.debug or similar) exec / .debug files
https://sourceware.org/bugzilla/show_bug.cgi?id=32063 Bug ID: 32063 Summary: let debuginfod-find locate pre-installed (/usr/lib/.debug or similar) exec / .debug files Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Sometimes a user will go to the trouble of dnf-installing some debuginfo, or some executable may still be the live one in /usr/bin/* (rather than expired due to a dnf-update, with an old copy still running). If so, debuginfod-find might want to return paths to system location files rather than the debuginfod cache. This might not be necessary or appropriate in the client side C code, as it is usually invoked as a *fallback* to system paths not being found. ... But some applications might directly call debuginfod_find_* APIs, rather than the searching elfutils paths, in which case looking in system paths might be appropriate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23528] When executing ./eu-nm or ./eu-readelf -aAdehIlnrsSVcp -w, AddressSanitizer catch a double-free crash.
https://sourceware.org/bugzilla/show_bug.cgi?id=23528 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- FWIW, is there some technical reason why an .zdebug section couldn't possibly ALSO be SHT_COMPRESSED ? i.e., compressed twice for some reason by the generator? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/24488] ebl_openbackend might use wrong library search path
https://sourceware.org/bugzilla/show_bug.cgi?id=24488 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Frank Ch. Eigler --- Is it worth reconsidering the dynamic loading model for libebl? Each target backend consists of about 30kB of stripped .so content, for half a megabyte in total. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/24856] dwarf_diename() cannot get correct name
https://sourceware.org/bugzilla/show_bug.cgi?id=24856 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com Resolution|--- |INVALID --- Comment #4 from Frank Ch. Eigler --- as per comment #3, the test was based on a misunderstanding of the libdw api -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25365] New: debuginfod client cleanup safety: restrict to client-pattern files
https://sourceware.org/bugzilla/show_bug.cgi?id=25365
Bug ID: 25365
Summary: debuginfod client cleanup safety: restrict to
client-pattern files
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: debuginfod
Assignee: amerey at redhat dot com
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
During cache cleanup, we should only erase files that match the pattern of file
names that we ourselves wrote (HEXCODE/{debuginfo,executable,source}), in
order to avoid nuking contents of a general directory if a user mis-sets
$DEBUGINFOD_CACHE_PATH .
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/25366] New: debuginfod scan: more progress/status
https://sourceware.org/bugzilla/show_bug.cgi?id=25366 Bug ID: 25366 Summary: debuginfod scan: more progress/status Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: fche at redhat dot com Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- With the workqueue based scanning, there is less progress information available on the console. A periodic report should show data like the last file that was processed by each thread. prometheus metrics should include their counters. prometheus metrics could include string status contents as comments. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25367] New: web request status logging improvements
https://sourceware.org/bugzilla/show_bug.cgi?id=25367 Bug ID: 25367 Summary: web request status logging improvements Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- debuginfod log webapi GET requests after completion, so they can include a data amount and precise service-time measurement -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25368] New: handle native golang buildids
https://sourceware.org/bugzilla/show_bug.cgi?id=25368 Bug ID: 25368 Summary: handle native golang buildids Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Native golang puts unique buildids into a .note.go.buildid section, with a much longer textual string than our normal 20-byte blob. debuginfod would need to add these to the index, and golang debuginfo consumers would have to learn to pass it. hex-encoding the textual golang buildid should make it fit right into the webapi, instead of worrying about '/' characters embedded inside. RHEL packaged golang binaries get a normal gnu-style buildid also as a part of package postprocessing, so this functionality may not be required there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25369] New: make DEBUGINFOD_PROGRESS prettier
https://sourceware.org/bugzilla/show_bug.cgi?id=25369 Bug ID: 25369 Summary: make DEBUGINFOD_PROGRESS prettier Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- It would be interesting to also print the URL being fetched, or other such textual status. This is probably most easily implemented by extending the debuginfod_client object with some progress-related state, which at some point could be externalized with new API ... or not. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25370] New: container image/registry scanning
https://sourceware.org/bugzilla/show_bug.cgi?id=25370 Bug ID: 25370 Summary: container image/registry scanning Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org, lberk at redhat dot com Target Milestone: --- There may be a use case where debuginfo-carrying container images are available on registries or filesystems, and where extracting that content could serve container debugging tasks. hypothetical algorithm: - given a list of image names - periodically make contact with designated registry across https://docs.docker.com/registry/spec/api/ - fetch authentication token if needed - download image manifest json, thence layer fs-delta files (tarballs) - scan resulting tarballs as ordinary libarchive inputs - use fs-delta blob hexid as archive path key - need only ever scan once! - https://gist.github.com/cirocosta/17ea17be7ac11594cb0f290b0a3ac0d1 or podman-intermediated: - given a list of image names - perform periodic "podman pull"s - podman mount - scan contents in -F mode - "podman unmount" afterwards - ... or podman save; scan the resulting tarball's contents as sub tarballs - one problem is how to scan only new layers (and not waste time instantiating old at all) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25375] New: optimization: speculative fdcache'ing of peers in decompressed archive
https://sourceware.org/bugzilla/show_bug.cgi?id=25375 Bug ID: 25375 Summary: optimization: speculative fdcache'ing of peers in decompressed archive Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Consider a systemtap test run against debuginfod. There are some test cases that ask for probes of numerous kernel modules. Each of these is submitted to debuginfod - sequentially - and each one can result in a separate rpm2cpio job to decompress the same kernel-debuginfo rpm. We should consider adding an option to fdcache with the effect that: if we're decompressing an archive for a genuine request, anticipate that there may be near-future requests for other files in the archive, and therefore decompress & intern them all in fdcache. This would trade fdcache storage space for decompression time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25394] New: groom vs. scan race condition
https://sourceware.org/bugzilla/show_bug.cgi?id=25394 Bug ID: 25394 Summary: groom vs. scan race condition Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: fche at redhat dot com Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- The grooming thread tries to nuke orphan buildid records (those with no d/e/s type payload records pointing to them). This can race with the stages of creation of a payload record in the scanner threads, wherein a buildid record is interned first, then the referring d/e/s record is written. If these are interleaved just right, the d/e/s record will be disallowed, so the file or archive data will be incomplete. Worse, since the size/mtime payload record is still written (because the scanner threads think d/e/s was successful), a later scan pass will not try to rescan the affected file/archive either. We need some A(tomicity) in the scanner threads (a transaction that includes the interning and the payload inserts). And we probably need a schema reset, just so possibly incomplete databases are regenerated correctly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25415] New: segv on empty search path
https://sourceware.org/bugzilla/show_bug.cgi?id=25415 Bug ID: 25415 Summary: segv on empty search path Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: fche at redhat dot com Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- commit 32ed4e6f8 (unreleased) introduced a bug with runs such as % debuginfod -R without a path, because fts(3) is not defined to operate with zero path names. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25415] segv on empty search path
https://sourceware.org/bugzilla/show_bug.cgi?id=25415 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- commit c02dfd95e3d merged as obvious -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25394] groom vs. scan race condition
https://sourceware.org/bugzilla/show_bug.cgi?id=25394 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- commit 34e67018914cf9ebbef07065965755b6554fd66e let's try to put out of our minds the four subsequent cleanup patches -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25375] optimization: speculative fdcache'ing of peers in decompressed archive
https://sourceware.org/bugzilla/show_bug.cgi?id=25375 --- Comment #1 from Frank Ch. Eigler --- prototype is commit b5ba87c835ba -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25461] New: add /etc/profile.d/* files for default $DEBUGINFOD_ env var settings for distro
https://sourceware.org/bugzilla/show_bug.cgi?id=25461 Bug ID: 25461 Summary: add /etc/profile.d/* files for default $DEBUGINFOD_ env var settings for distro Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25493] --enable-debuginfod fails if CXX is set
https://sourceware.org/bugzilla/show_bug.cgi?id=25493 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=14d5b412dc3baef19bc993c83acdb750fc7e194f fixes --- a/configure.ac +++ b/configure.ac @@ -687,18 +687,18 @@ fi # both client and server. AC_ARG_ENABLE([debuginfod],AC_HELP_STRING([--enable-debuginfod], [Build debuginfod server and client])) AC_PROG_CXX -AX_CXX_COMPILE_STDCXX(11, noext, optional) AS_IF([test "x$enable_debuginfod" != "xno"], [ -AC_MSG_NOTICE([checking debuginfod dependencies, disable to skip]) +AC_MSG_NOTICE([checking debuginfod C++11 support, --disable-debuginfod to skip]) +AX_CXX_COMPILE_STDCXX(11, noext, mandatory) +AC_MSG_NOTICE([checking debuginfod dependencies, --disable-debuginfod to skip]) enable_debuginfod=yes # presume success PKG_PROG_PKG_CONFIG -if test "x$ac_cv_prog_ac_ct_CXX" = "x"; then enable_debuginfod=no; fi PKG_CHECK_MODULES([libmicrohttpd],[libmicrohttpd >= 0.9.33],[],[enable_debuginfod=no]) PKG_CHECK_MODULES([libcurl],[libcurl >= 7.29.0],[],[enable_debuginfod=no]) PKG_CHECK_MODULES([sqlite3],[sqlite3 >= 3.7.17],[],[enable_debuginfod=no]) PKG_CHECK_MODULES([libarchive],[libarchive >= 3.1.2],[],[enable_debuginfod=no]) if test "x$enable_debuginfod" = "xno"; then - AC_MSG_ERROR([C++ compiler or dependencies not found, use --disable-debuginfod to disable.]) + AC_MSG_ERROR([dependencies not found, use --disable-debuginfod to disable.]) fi ]) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/25498] New: support reading /usr/src/kernels/...../vmlinux.id as buildid for kernel images
https://sourceware.org/bugzilla/show_bug.cgi?id=25498 Bug ID: 25498 Summary: support reading /usr/src/kernels/./vmlinux.id as buildid for kernel images Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Some linux kernel install images lack anything resembling the ELF file that elfutils can read - even after x86 vmlinuz-style unwrapping/decompression. For example, arm64 butchers the poor vmlinux via objdump -O binary -R .note.gnu.build-id etc. in linux arch/arm64/boot/Makefile That leaves us nothing to extract a buildid, with which find_debuginfo() could reach out to debuginfod. "No, there is another." --- random jedi guy Yes, find_debuginfo() for the kernel only, could also snoop on the file /usr/src/kernels/`uname -r`/vmlinux.id which contains the buildid hex string, as a part of the kernel-devel subrpm on fedora/rhel-ish packaging at least. (No such luck on debian/ubuntu so far.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #3 from Frank Ch. Eigler --- Indeed, merely splitting the package up does not solve problematic incoming dependencies. IMHO we should encourage distros to have a bootstrap-oriented build of elfutils, possibly prepared thusly: - have the elfutils configury have a -debuginfod mode (--without-debuginfod?) that, instead of just skipping building all that stuff, builds a no-op stub instead - expose that --without-debuginfod configure flag to another spec file (or a --with-* flagged version of the main one) to generate a set of elfutils-bootstrap-* subrpms - have the normal non-bootstrap spec file variant Obsolete/Conflict with the bootstrap siblings - then these elfutils-bootstrap* rpms should be functional and satisfy all your bootstrapping needs - and after bootstrapping is done, nuke the elfutils-bootstrap rpms from your repo, and build the real thing -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/25525] configure: error: gcc with GNU99 support required
https://sourceware.org/bugzilla/show_bug.cgi?id=25525 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-10 CC||fche at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Frank Ch. Eigler --- key bits: x86_64-apple-darwin18.7.0 I wonder if on this machine, llvm pretends to be gcc. What does "gcc -v" say? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25548] New: also support canonicalized source-file name lookups in webapi
https://sourceware.org/bugzilla/show_bug.cgi?id=25548 Bug ID: 25548 Summary: also support canonicalized source-file name lookups in webapi Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org, jan.kratochvil at redhat dot com, kkleine at redhat dot com Target Milestone: --- It turns out that some debuginfo consumers canonicalize source-code file names by the time they get the convenient chance to fall back to debuginfod. This means that path substrings that POSIX defines as no-ops are lost. debuginfod should extend a gracious embrace to these tools by also permitting such paths to be used during the /buildid/hexcode/source/PATH webapi. Implementing this should not be too hard. The dwarf_extract_source_paths could add both waldo and a new canonicalize_posix_path(waldo) to the returned debug_sourcefiles[] set. That's it. The canonicalize_posix_path() function would perform these textual rewrites, repeating until convergence: /./ -> / /FOO/../ -> /# NB: FOO must not be . or .. because /../../ != / //-> / (realpath(3) is not helpful because it looks at the host filesystem to do resolution, which we cannot when dealing with archive-resident file names.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25365] debuginfod client cleanup safety: restrict to client-pattern files
https://sourceware.org/bugzilla/show_bug.cgi?id=25365 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- commit 889edd912ccb -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25583] Use libarchive to extract packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-22 CC||fche at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Frank Ch. Eigler --- Interesting idea. OTOH, rpm2cpio and dpkg binaries are not too hard to come by. One can experiment with the former already with git-master debuginfod with the "-Z .rpm" option instead of "-R". Performance seems to be roughly the same. The latter is less compelling in that it'd require hard-coding the inner data.tar.xz name and its processing ... meh. Maybe the status quo is good enough? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25369] make DEBUGINFOD_PROGRESS prettier
https://sourceware.org/bugzilla/show_bug.cgi?id=25369 Frank Ch. Eigler changed: What|Removed |Added Assignee|unassigned at sourceware dot org |fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- drafting extensions to the client side api to make this usable -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25583] Use libarchive to extract packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 Frank Ch. Eigler changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #3 from Frank Ch. Eigler --- ok, confirmed that relatively old bsdtar (libarchive 3.1.2 rhel7) supports rpm natively too. Will switch that over as Mark suggests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25375] optimization: speculative fdcache'ing of peers in decompressed archive
https://sourceware.org/bugzilla/show_bug.cgi?id=25375 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Frank Ch. Eigler --- commit 577170fc84e1 includes slight merge tweaks from previous version -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25583] Use libarchive to extract packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 Frank Ch. Eigler changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Frank Ch. Eigler --- pushed as obvious diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx index be3868bb1e42..7c7e85eb6d14 100644 --- a/debuginfod/debuginfod.cxx +++ b/debuginfod/debuginfod.cxx @@ -426,7 +426,7 @@ parse_opt (int key, char *arg, break; case 'F': scan_files = true; break; case 'R': - scan_archives[".rpm"]="rpm2cpio"; + scan_archives[".rpm"]="cat"; // libarchive groks rpm natively break; case 'U': scan_archives[".deb"]="dpkg-deb --fsys-tarfile"; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25600] New: debuginfo-client should handle file:// URLs
https://sourceware.org/bugzilla/show_bug.cgi?id=25600
Bug ID: 25600
Summary: debuginfo-client should handle file:// URLs
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: debuginfod
Assignee: unassigned at sourceware dot org
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
While this may be useful only for local testing, it's still good to have.
It's being blocked by error handling logic in -client.c line 728ish, as
identified by kkleine, because the 200 response code is only valid for http.
file:// scheme returns 0 for success here. So this code would need to do
some scheme-sensitive logic, such as curl's own src/tool_operate.c:
if(CURLE_OK == result) {
char *effective_url = NULL;
curl_easy_getinfo(curl, CURLINFO_EFFECTIVE_URL, &effective_url);
if(effective_url &&
curl_strnequal(effective_url, "http", 4)) {
/* This was HTTP(S) */
curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response);
if(response != 200 && response != 206) {
i.e., if result was CURLE_OK, assume success,
unless http and we have a bad response code.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/25607] New: debuginfod-client: paranoid federation mode
https://sourceware.org/bugzilla/show_bug.cgi?id=25607 Bug ID: 25607 Summary: debuginfod-client: paranoid federation mode Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- It may be helpful to have a debuginfod_client option (env var? api?) that adds a degree of paranoia to frontend debuginfod servers that simply federate out to multiple mostly-trustworthy upstreams. The present code simply launches the outgoing curl requests to -all- upstream servers in $DEBUGINFOD_URLS, and the first one that starts sending data back is selected as the winner. The data from the others is thrown away. This is fine if all the servers are trustworthy, correct, etc. etc. With a bit of extra code, we can detect some kinds of shenanigans or errors. One possibility is teaching the -client code to -not- choose the first upstream server as the winner, but to wait for them all to send back a definite response (subject to a timeout). Then it can compare the responses from those servers that claimed to know the buildid/$payload. If there is a mismatch, signal a loud error, as though there were a RAID-1 disagreement between mirrored disks. With such checking logic in place, it is possible to proactively scan the federated server tree by mechanically looking up all "interesting" buildids. It could permit the assembly of a semi-trusted tree of servers that still limit client exposure to wrong data. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #6 from Frank Ch. Eigler --- (In reply to Eli Schwartz from comment #5) > > # Look for libmicrohttpd, libcurl, libarchive, sqlite for debuginfo server > > # minimum versions as per rhel7. Single --enable-* option arranges to build > > # both client and server. > > Maybe this should not be the case? If libdebuginfod was enabled on its own > as long as libcurl is available, this would make things a lot simpler. At > least for Arch Linux, curl is part of the base system while libmicrohttpd is > not. This part wouldn't affect the suse/fedora folks, because one would already place the debuginfod server into a separate subpackage, so its prereqs don't affect the buildroot. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25548] also support canonicalized source-file name lookups in webapi
https://sourceware.org/bugzilla/show_bug.cgi?id=25548 --- Comment #4 from Frank Ch. Eigler --- Related to this, Eli Schwartz helped identify two separate outright bugs in the code that touch on this problem. The debuginfod-client.c curl api code neglects to pass CURLOPT_PATH_AS_IS, so source file references with /../ bits in them get collapsed. This is the opposite of what the webapi docs say. The above bug hid a separate bug in the server. There, an inconsistent canonicalization rule is in effect with archives. srefs are uncanonicalized, but sdefs are canonicalized. That makes those source queries unsatisfiable. Whoops. The cure should consist of: - adding CURLOPT_PATH_AS_IS to the client, where I swear it was at one point - teaching the server to store both canonicalized AND uncanonicalized artifactsrc names in the _f_s and _r_sref tables (so up to two rows instead of just one) and then bob will in fact be our uncle. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25583] Use libarchive to extract .deb packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 --- Comment #6 from Frank Ch. Eigler --- > -# For /usr/bin/cpio2rpm > -Requires: rpm Heh, that was always moot on an rpm based system (.spec file!). > +# To extract .deb files with dpkg-deb --fsys-tarfile > +# Can be Recommends if rpm supports that > +Requires: dpkg Sure, as long as one remembers to remove it from rhel distros that have dpkg only in epel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25628] client should cache negative results
https://sourceware.org/bugzilla/show_bug.cgi?id=25628 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- debuginfod misses are pretty quick tho - maybe it's harmless? If these are to be cached, they shouldn't be cached too long, as the data could appear later. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] New: client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 Bug ID: 32318 Summary: client should avoid url duplication for different ima:FOO modes Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Even with IMA stuff going into debuginfod/-client in 0.192ish, we can't in good conscience enable ima:enforcing as a mode for fedora. That's because it's possibly risky: breaking some downloads if anything's wrong with the signature data over at the server archive, which could happen due to build system inconsistencies or other unknown factors. (We don't have a census.) So in the absence of that certainty, an ima:permissive mode like bug #31842 pleads for could do the job. In the absence of that mode, this would be a way of emulating it: DEBUGINFOD_URLS="ima:enforcing https://debuginfod.fedoraproject.org ima:ignore https://debuginfod.fedoraproject.org"; but the debuginfod client code duplicate-eliminates the two occurrences of the same URL, defeating the purpose. So we need to get the client code to consider ima mode when dupe eliminating. Let's track this change here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/32186] New: eu-unstrip should search for debuginfo via debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=32186 Bug ID: 32186 Summary: eu-unstrip should search for debuginfo via debuginfod Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- eu-unstrip always requires two files on its command line. If one's a normal stripped binary on a Proper distro, eu-unstrip should be able to find the corresponding debuginfo by debuginfod queries. (Unfortunately, % eu-unstrip BINARY `debuginfod-find debuginfo BINARY` almost works, except that eu-unstrip wants to write into the second file, which is in the (read-only) debuginfo cache.) Let's consider giving eu-unstrip a mode where, given a single file (a stripped executable), it'll download debuginfo if possible, then rewrite the file as unstripped. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32184] New: add dwo/dwp support
https://sourceware.org/bugzilla/show_bug.cgi?id=32184 Bug ID: 32184 Summary: add dwo/dwp support Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Assuming consumer tools like gdb would contemplate using it, debuginfod could in principle also accept ".dwo" files with their DW_AT_GNU_dwo_name and/or DW_AT_GNU_dwo_id as key, and ".dwp" files as an archive of ".dwo"s. The existing C/webapis should be usable unmodified, as long as the dwo name/id tags are unique enough in the environment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32184] add dwo/dwp support
https://sourceware.org/bugzilla/show_bug.cgi?id=32184 --- Comment #1 from Frank Ch. Eigler --- See also: https://inbox.sourceware.org/elfutils-devel/cak2qhjefgpty1a77jwt-avrxpen8wi+am85wuagd-xv+8df...@mail.gmail.com/#r bug #31360 bug #19914 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32629] add setter functions to debuginfod_client object as alternative to getenv/setenv
https://sourceware.org/bugzilla/show_bug.cgi?id=32629 --- Comment #2 from Frank Ch. Eigler --- The _begin function is already a constructor, :-) it just doesn't take such parameters. There are other env vars that we take as inputs too, and it would be odd to take just one as a function parameter here. And then it needs to be fixed for the life of the object? Dunno if that makes sense. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32629] add setter functions to debuginfod_client object as alternative to getenv/setenv
https://sourceware.org/bugzilla/show_bug.cgi?id=32629 Frank Ch. Eigler changed: What|Removed |Added Summary|add setter functions to |add setter functions to |debuginfod_client object as |debuginfod_client object as |alternative go |alternative to |getenv/setenv |getenv/setenv -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32629] New: add setter functions to debuginfod_client object as alternative go getenv/setenv
https://sourceware.org/bugzilla/show_bug.cgi?id=32629 Bug ID: 32629 Summary: add setter functions to debuginfod_client object as alternative go getenv/setenv Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- We'd need a cumulative environ-like array-of-strings, probably. Or else, individual strings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/32540] dwarf_errno() error codes are private
https://sourceware.org/bugzilla/show_bug.cgi?id=32540 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #3 from Frank Ch. Eigler --- (In reply to Mark Wielaard from comment #1) > They are intentionally private implementation details. If the exact > constants and names were public they would become part of the API and the > exact error returned couldn't be changed anymore. That doesn't follow. API functions can be documented to return a mixture of fixed and varying pools of error codes. If any of the errors are such that a library client could possibly take action to correct them, then they should be machine readable error indications, not English text. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32559] New: nit: debuginfod client callback size parameter sometimes wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=32559 Bug ID: 32559 Summary: nit: debuginfod client callback size parameter sometimes wrong Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- While testing out the IMA recipe on the elfutils/Debuginfod.html page, ran into this little peculiarity: url 0 https://debuginfod.elfutils.org/buildid/1ba84b92a0ae2a9fa2f1b8033a583c6eb223c204/debuginfo query 1 urls in parallel header HTTP/1.1 200 OK header Date: Tue, 14 Jan 2025 19:43:22 GMT header Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_qos/11.70 header Cache-Control: public header Last-Modified: Wed, 17 Jan 2024 00:00:00 GMT header X-DEBUGINFOD-IMASIGNATURE: 030204388b603e00473045022100cc4af897e4b66b35ae851b1e3a7b0a69f522a00bb420f1e412760b26f0addf7b02205581d79e88800044bd05ed83eb957b48fb6179ae76b6145307edebd6cc29f98f header X-DEBUGINFOD-FILE: /usr/lib/debug/usr/bin/klist-1.21.2-3.fc39.x86_64.debug header X-DEBUGINFOD-ARCHIVE: /mnt/fedora_koji_prod/koji/packages/krb5/1.21.2/3.fc39/x86_64/krb5-workstation-debuginfo-1.21.2-3.fc39.x86_64.rpm header X-DEBUGINFOD-SIZE: 62112 header Content-Type: application/octet-stream header Vary: Accept-Encoding header Content-Encoding: gzip header Strict-Transport-Security: max-age=16070400 header Access-Control-Allow-Origin: * header Content-Length: 23380 [...] Downloading from https://debuginfod.elfutils.org/ 62112/23380 Note the odd denominator. I suspect it's caused by the unusual situation where this particular debuginfod server, bless its heart, can supply both Content-Length (post-compression size) and X-DEBUGINFOD-SIZE (pre-compression size) in its response header. The client should prefer the latter to the former if both are there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 Frank Ch. Eigler changed: What|Removed |Added Assignee|unassigned at sourceware dot org |fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- Created attachment 15951 --> https://sourceware.org/bugzilla/attachment.cgi?id=15951&action=edit possible implementation -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 --- Comment #2 from Frank Ch. Eigler --- While thinking through implications of this change and the preexisting configuration possibilities, I happened across this unfortunate finding, added to doc/debuginfod-client-config.7 It is possible for IMA configurations to be ambiguous, for example if a requested object is queried through a \fBDEBUGINFOD_URLS\fP specification that includes \fImultiple\fP servers with \fIdifferent\fP \fIima:\fP policy modes. Consider if the object is available from each of those servers, but with an absent or invalid signature. The client may query all servers concurrently. If the client happens to receive the object from an \fIima:enforcing\fP policy server first, the query will rejected, but if it's from an \fIima:ignore\fP policy server, the query will succeed. Let's assume this isn't easily avoidable. If so, then the possible implementation patch attachment is pointless, because its results in the subject case will be flatly in the ambiguous category. (The code above happens to squash it into ima:ignore, but that's an implementation artifact accident.) It is definitely NOT equivalent to the "ima:permissive" mode we have repeatedly discussed and noted in bug #31842. (The multiple-modes ambiguity would remain EVEN IF we had a first class ima:permissive mode.) (Why is this not easily avoidable? One reason relates to the way we use libcurl. We deliberately launch multiple outgoing queries to named servers concurrently. As soon as any one starts feeding us data, we abort the queries to all the others, to avoid downloading something potentially large multiple times. It's non-deterministic.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Frank Ch. Eigler --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701 Frank Ch. Eigler changed: What|Removed |Added Resolution|FIXED |NOTABUG --- Comment #10 from Frank Ch. Eigler --- > Meaning that, the choice of how to react when an environment variable is > missing is a decision made by the program, it can report and error or > it can use an empty string and proceed or it can use some default like > "/" and proceed. I suppose so. The latter is fine too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/32682] in configure, __asm__ should be used instead of asm
https://sourceware.org/bugzilla/show_bug.cgi?id=32682 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #5 from Frank Ch. Eigler --- > I have a predefined CFLAGS settings that includes `-std=c99` ... but why? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #3 from Frank Ch. Eigler --- An environment that has no $HOME nor $XDG_CACHE_HOME set is unusual enough not to warrant error messages even better than what gdb already printed (EPERM). GDB is probably attempting to access the RPM database so it can suggest debuginfo RPMs to install, given that its debuginfod-based attempts failed. I don't see any bug here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32701] gdb is attempting to write to / and write to rpm's database for no reason.
https://sourceware.org/bugzilla/show_bug.cgi?id=32701
--- Comment #7 from Frank Ch. Eigler ---
It is normal to build paths like getenv("HOME") + "/" + str(something),
so if $HOME is unset, you still get a "/" to start with.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/31862] debuginfod client should cache received x-debuginfod-* headers
https://sourceware.org/bugzilla/show_bug.cgi?id=31862 --- Comment #1 from Frank Ch. Eigler --- proposed patch https://inbox.sourceware.org/elfutils-devel/20250221200714.ga7...@redhat.com/T/#u -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/32318] client should avoid url duplication for different ima:FOO modes
https://sourceware.org/bugzilla/show_bug.cgi?id=32318 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Frank Ch. Eigler --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/33062] New: speed up readelf default (not -N) symbol resolution
https://sourceware.org/bugzilla/show_bug.cgi?id=33062 Bug ID: 33062 Summary: speed up readelf default (not -N) symbol resolution Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- elfutils readelf defaults to symbol resolution of addresses found in dwarf references; binutils readelf doesn't. The performance implication of this default is stark. Operating on a large c++ binary (stap): - binutils readelf -w|| 7.24s user 0.17s system 99% cpu 7.432 total - stock eu-readelf -w|| 582.05s user 0.09s system 99% cpu 9:43.47 total - stock eu-readelf -w -N || 3.88s user 0.04s system 99% cpu 3.930 total i.e. a factor of ~200 slowdown. Surely it can be made faster. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589 Frank Ch. Eigler changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Frank Ch. Eigler --- Can reexamine if given a newer reproducer w/ dwarf binary. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/33040] RFE: debuginfod could support other databaase backends
https://sourceware.org/bugzilla/show_bug.cgi?id=33040 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- What benefits are these teams looking for, by delegating database storage to a whole separate service? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/33040] RFE: debuginfod could support other databaase backends
https://sourceware.org/bugzilla/show_bug.cgi?id=33040 --- Comment #3 from Frank Ch. Eigler --- > This wouldn't have happened if the service had been using their > already-deployed pgsql instance. I see what you mean - though whatever growing storage would have to have been allocated at that database server instead. Anyway, I'm in no way opposed to debuginfod growing another database backend, as long as sqlite is still in there, and support for both is tastefully integrated rather than stomach-pumping. :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29478] Slow query of a debuginfo in a big rpm with very many files
https://sourceware.org/bugzilla/show_bug.cgi?id=29478 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Frank Ch. Eigler --- Unfortunately, we're not aware of an easy way around this. There is no way to seek in the compressed files to an arbitrary index, so one is stuck reading from the beginning to the file of interest. I think that, unless the kernel packaging changes, one needs to rely on (trigger!) debuginfod to fetch & cache highly likely files such as the vdso*. Some work is underway to allow this automation, but until then, make sure your debuginfod server has a large enough fdcache, and you don't groom too frequently (which clears out the fdcache). See also https://bugzilla.redhat.com/show_bug.cgi?id=1970578 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29474] Server returns 404 for concurrent requests when leading to a same .rpm
https://sourceware.org/bugzilla/show_bug.cgi?id=29474 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Frank Ch. Eigler --- elfutils-0.187-44-g31d6b1fe7 / debuginfod/ChangeLog debuginfod/debuginfod.cxx: PR29474: debuginfod -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28284] support description functionality through HEAD
https://sourceware.org/bugzilla/show_bug.cgi?id=28284 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Frank Ch. Eigler --- commit 8760e931abf33ed2b215809d5ebf653ced934152 Author: Frank Ch. Eigler Date: Fri Sep 2 12:41:38 2022 -0400 PR28284: add tweaks on previous debuginfod x-debuginfod* header forwarding work Embrace case-independent headers, more fully document, handle HTTP \r. In addition to test case, hand-tested against fedora debuginfod instances, running federated servers under valgrind. Signed-off-by: Frank Ch. Eigler commit bbc2ca6d553f0ce3e670303ac9a3c764cf10d779 Author: Noah Sanci Date: Wed Jun 15 10:07:29 2022 -0400 PR28284 - Debuginfod header functionality implemented Debuginfod and debuginfod clients are now equipped to send and receive http headers prefixed with X-DEBUGINFOD and print them in verbose mode for more context Signed-off-by: Noah Sanci -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29696] New: intermittent libmicrohttpd assertion failures related to socket fd closing
https://sourceware.org/bugzilla/show_bug.cgi?id=29696 Bug ID: 29696 Summary: intermittent libmicrohttpd assertion failures related to socket fd closing Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- In a range of libmicrohttpd versions, up to and including libmicrohttpd-0.9.75-3.fc36.x86_64, debuginfod occasionally crashes with messages like: https://builder.sourceware.org/testrun/920819ee86861130393e12933821c5b544afeee4?filename=tests%2Frun-debuginfod-federation-metrics.sh.log#line1669 Fatal error in GNU libmicrohttpd daemon.c:3831: Failed to remove FD from epoll set. Even without MHD_USE_EPOLL, a nearly identical message can come from a different code path. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29711] In libdw.h struct Dwarf, struct Dwarf_Abbrev is defined using typedef and not using #include is not the way to comply with the specification?
https://sourceware.org/bugzilla/show_bug.cgi?id=29711 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2022-10-21 Ever confirmed|0 |1 CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- No specification requires elfutils to provide an other than forward declaration of these types. Keeping the definitions private is fine, given that opaque pointers are used in the various libdw* api calls to clients. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/29786] Unable to understand, in objdump, the user is not using the name, so using a.out
https://sourceware.org/bugzilla/show_bug.cgi?id=29786 Frank Ch. Eigler changed: What|Removed |Added Resolution|--- |NOTABUG CC||fche at redhat dot com Status|UNCONFIRMED |RESOLVED --- Comment #1 from Frank Ch. Eigler --- Why not use an empty string as a filename? A user can type eu-objdump "" to pass an empty string if that's really what she wants. Defaulting to "a.out" in the absence of a filename is traditional. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29926] debuginfod using deprecated curl (since 7.55.0) API, fails to build with 7.87.0
https://sourceware.org/bugzilla/show_bug.cgi?id=29926 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||fche at redhat dot com --- Comment #2 from Frank Ch. Eigler --- Thanks, merged! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29975] Search concurrency doesn't respect CPU affinity
https://sourceware.org/bugzilla/show_bug.cgi?id=29975 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- > number of cores available to it (sched_getaffinity()). Do you happen to be aware of a c++y front-end to this, which we could use instead of std::thread::hardware_concurrency() ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29976] webapi connection pool eats all file handles
https://sourceware.org/bugzilla/show_bug.cgi?id=29976 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- What sets "ulimit -n -> 1000" in your case? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29976] webapi connection pool eats all file handles
https://sourceware.org/bugzilla/show_bug.cgi?id=29976 --- Comment #4 from Frank Ch. Eigler --- I assume "debuginfod -C $num -d $num" still works for you, in this battle of distro/site defaults. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29982] sqlite errors when searching
https://sourceware.org/bugzilla/show_bug.cgi?id=29982 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2023-01-10 Status|UNCONFIRMED |WAITING --- Comment #2 from Frank Ch. Eigler --- Please supply a command line invocation for us to try to reproduce this, along with version numbers of ubuntu / debuginfod / sqlite3. This could happen if the database is actually a normal file instead of :memory:, and two separate debuginfod instances are trying to write to the same one. (debuginfod -d :memory: is already tested on debian etc. as a part of the testsuite. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29982] sqlite errors when searching
https://sourceware.org/bugzilla/show_bug.cgi?id=29982 --- Comment #6 from Frank Ch. Eigler --- Please confirm the complete command line. % debuginfod -d:memory creates a file named ":memory", not an in-memory sqlite database alias ":memory:") -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29982] sqlite errors when searching
https://sourceware.org/bugzilla/show_bug.cgi?id=29982 --- Comment #9 from Frank Ch. Eigler --- Perhaps a complete highly verbose trace (-vvv) would help identify the cause. Scanning threads should not be able to lock each other out for O(1sec) from sqlite operations in normal circumstances. OTOH, one can rest assured that in case of such sqlite problems, debuginfod just treats them as transient and retries the related scan operation later. Webapi service threads do not contend with the others at all, so clients don't see these transient errors. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29976] webapi connection pool eats all file handles
https://sourceware.org/bugzilla/show_bug.cgi?id=29976 --- Comment #6 from Frank Ch. Eigler --- please check out commit 7399e3bd7eb72d045 on elfutils.git for a test patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/29975] Search concurrency doesn't respect CPU affinity
https://sourceware.org/bugzilla/show_bug.cgi?id=29975 --- Comment #3 from Frank Ch. Eigler --- please check out commit 7399e3bd7eb72d045 on elfutils.git for a test patch -- You are receiving this mail because: You are on the CC list for the bug.
