Description of problem: When trying to build a RPM on a machine, check-rpath is hanging when running readelf on a ELF shared library Digging deeper with strace, it seems that readelf is trying to reach the IP 38.165.60.21 on port 443 The problem is that this is blocked by a firewall Version-Release number of selected component (if applicable): 2.37-27 How reproducible: Always behind the firewall, work on an other network Steps to Reproduce: 1. Run readelf executable with port 443 packets dropped by the network Actual results: readelf blocks (forever?) Expected results: readelf outputs the information about the ELF file and/or should not try to reach the debuginfo service Additional info:
Hi Laurent, Attempting to contact the debuginfod server is the new default behaviour for readelf (unless configured differently when the readelf binary was built). There is however a command line option to disable this behaviour: -wE or --debug-dump=do-not-use-debuginfod if you prefer the long version. If this option is added to the check-rpaths-worker script, then the problem should go away. As such I would like to reassign this BZ to the "rpm" component. Do you agree ? Cheers Nick
Hello Nick, That indeed can be a solution, but I'm also wondering why there is no timeout if the debug info cannot be fetched So maybe something needs to be changed here too?
(In reply to Laurent Bigonville from comment #2) > That indeed can be a solution, but I'm also wondering why there is no > timeout if the debug info cannot be fetched > > So maybe something needs to be changed here too? The debuginfod client library does not provide a means for an application (eg readelf) to set a timeout, but it does support a DEBUGINFOD_TIMEOUT environment variable. So this is something else that check-rpaths-worker could use.
(In reply to Laurent Bigonville from comment #2) > Hello Nick, > > That indeed can be a solution, but I'm also wondering why there is no > timeout if the debug info cannot be fetched > > So maybe something needs to be changed here too? In addition to manually setting the DEBUGINFOD_TIMEOUT environment variable like Nick pointed out, there should be a default timeout of 90 seconds.
(In reply to amerey from comment #4) > In addition to manually setting the DEBUGINFOD_TIMEOUT environment variable > like Nick pointed out, there should be a default timeout of 90 seconds. There is a default timeout and it is 90 seconds. Since you say that readelf is hanging, something strange must be going on. I am going to set a needinfo request for Mark Weilaard, the debuginfod expert. Maybe he can shed some more light on the situation....
38.145.60.21 is debuginfod.fedoraproject.org which likely means you have DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ set (which is the default). The best way to debug debuginfod issues is by setting export DEBUGINFOD_VERBOSE=1 Set that and rerun readelf to see what it is trying to do. Other useful environment variables are (see man 7 debuginfod-client-config): $DEBUGINFOD_RETRY_LIMIT This environment variable governs the default limit of retry at‐ tempts. If a query failed with errno other than ENOENT, will initiate several attempts within the limit. $DEBUGINFOD_TIMEOUT This environment variable governs the download commencing time‐ out for each debuginfod HTTP connection. A server that fails to provide at least 100K of data within this many seconds is skipped. The default is 90 seconds. (Zero or negative means "no timeout".) $DEBUGINFOD_MAXTIME This environment variable dictates how long the client will wait to complete the download a file found on a server in seconds. It is best used to ensure that a file is downloaded quickly or be rejected. The default is 0 (infinite time). $DEBUGINFOD_MAXSIZE This environment variable dictates the maximum size of a file to download in bytes. This is best used if the user would like to ensure only small files are downloaded. A value of 0 causes no consideration for size, and the client may attempt to download a file of any size. The default is 0 (infinite size).
Would it also make sense to restrict debuginfod client activity until readelf actually needs debugging information? $ strace -econnect readelf -hW /bin/true ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Position-Independent Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x1960 Start of program headers: 64 (bytes into file) Start of section headers: 26520 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 13 Size of section headers: 64 (bytes) Number of section headers: 31 Section header string table index: 30 connect(9, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("38.145.60.21")}, 16) = -1 EINPROGRESS (Operation now in progress) connect(10, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("38.145.60.20")}, 16) = -1 EINPROGRESS (Operation now in progress) +++ exited with 0 +++
(In reply to Florian Weimer from comment #7) > Would it also make sense to restrict debuginfod client activity until > readelf actually needs debugging information? Probably. Is it safe to assume that any separate debug info file will only contain debug information + (possibly) symbol tables + (possibly) string tables ? If so, then we could avoid loading those files if we are not dumping that type of information.
Ok - I have applied a patch upstream which stops readelf and objdump from being so enthusiastic about following links to separate debug info files. More specifically it stops the program from following the links when the dump option(s) that are active do not require any debugging information. I have backport the patch to rawhide, and I am in the process of porting it to F36 and F35. Fixed in binutils-2.38-11.fc37
Now also fixed in: binutils-2.37-30.fc36 binutils-2.37-19.fc35
FEDORA-2022-d0c6475359 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d0c6475359
FEDORA-2022-ffad9aca7a has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ffad9aca7a
FEDORA-2022-d0c6475359 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-d0c6475359` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d0c6475359 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-ffad9aca7a has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ffad9aca7a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ffad9aca7a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-57015a1d06 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-57015a1d06` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-57015a1d06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-4300e4c941 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-4300e4c941` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4300e4c941 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6bb4a92d4f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6bb4a92d4f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6bb4a92d4f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-7a51ade8e5 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7a51ade8e5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a51ade8e5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e74fd85484 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e74fd85484` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e74fd85484 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-c60ef417af has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-c60ef417af` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c60ef417af See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-da31238a14 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-da31238a14` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-da31238a14 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-a46f1b2ba2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-a46f1b2ba2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a46f1b2ba2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e5a363e490 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e5a363e490` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e5a363e490 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-a46f1b2ba2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-e5a363e490 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.