Previous code sometimes confused debuginfod with concurrent queries
targeting the same RPM. One thread fetching & prefetching, the other
thread misinterpreted the sudden presence of its target file in the
fdcache as a mere unnecessary prefetch duplicate. But if it was the
other thread's target file, previous code would -skip- it completely,
resulting in a 404 error. New code allows the other thread to also
decompress the target file and return it, and still continue to its
own prefetching process for other files.
There's a performance trade-off here. Another option would be for the
other thread to check the fdcache regularly and abort its own
prefetch/fetch/prefetch loop early in case of a sudden target file
hit. That'd save CPU probably but it'd stop prefetching of later
segments of the input archive, which could save future time.
Automated testing is too time/load sensitive to attempt. Confirmed
working with Martin's stress tester.
Reported-By: Martin Liška <mliska@suse.cz>
Signed-Off-By: Frank Ch. Eigler <fche@redhat.com>
+2022-08-15 Frank Ch. Eigler <fche@redhat.com>
+
+ PR29474
+ * debuginfod.cxx (handle_buildid_r_match): Don't trigger false-404's
+ for concurrently prefetched target files.
+
2022-08-02 Josef Cejka <jcejka@suse.de>
* debuginfod.cxx (groom): Don't evaluate regex unless needed.
if ((r == 0) && (fn != b_source1)) // stage 1
continue;
- if (fdcache.probe (b_source0, fn)) // skip if already interned
+ if (fdcache.probe (b_source0, fn) && // skip if already interned
+ fn != b_source1) // but only if we'd just be prefetching, PR29474
continue;
// extract this file to a temporary file