Please see the dso_list file in bug #2070338. My understanding of that file is that it'll list all libraries loaded in time of the report. I'm missing glib2 libraries in this case.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still valid, see for example bug #2187837 or bug #2188823, there are a lot more (runtime) dependencies than what the dso_list attachment shows.
$ abrt-action-list-dsos -m /proc/$(pidof -s evolution-source-registry)/maps | grep glibc /usr/lib/locale/locale-archive glibc-all-langpacks-2.37-4.fc38.x86_64 (Fedora Project) 1682926389 /usr/lib64/libresolv.so.2 glibc-2.37-4.fc38.x86_64 (Fedora Project) 1682926390 /usr/lib64/libc.so.6 glibc-2.37-4.fc38.x86_64 (Fedora Project) 1682926390 /usr/lib64/libm.so.6 glibc-2.37-4.fc38.x86_64 (Fedora Project) 1682926390 /usr/lib64/ld-linux-x86-64.so.2 glibc-2.37-4.fc38.x86_64 (Fedora Project) 1682926390 It seems like DSOs are properly parsed when running the abrt command directly. This needs more investigation...
abrt gets the list of DSOs of a crashed process from journal. However, the list there seems to be truncated for some reason: https://stackoverflow.com/a/55694357
https://www.freedesktop.org/software/systemd/man/sd_journal_get_data.html# "Also note that, by default, data fields larger than 64K might get truncated to 64K. This threshold may be changed and turned off with sd_journal_set_data_threshold()." That I think explains the problem. ABRT needs to adjust the threshold.
Rather than adjusting system setting, could there be used an output of the `ldd` or `lsof` command (`lsof -F -p ${PID} | grep \\.so`), parsed somehow and provide the information on its own? There is that `open_fds` attachment, which seems to be filtered to show only some of the file descriptors).
That would be simple, but coredumps are initially intercepted by systemd/coredumpctl, which dumps information about them into the journal. ABRT finds them there and extract + process information that was stored there by coredumpctl. So by the time ABRT is involved in all this, the /proc/<pid>/ is gone as the process died. I didn't have time to dig into this deeper last week, but it seems like the content of /prod/<pid>/maps is truncated in journal for some unknown reason and therefore ABRT cannot even get the full list of DSO... and this is the case regardless of whether we tweak sd_journal_set_data_threshold() on our side or not... so this might be a bug in how coredumpctl reads the data, or how it stores the data in journal. But like I said, this still needs more investigation...
Aha, okay, it was only an idea. Once upon a time, ABRT used to call gdb on its own, and I thought it does that with the running process. I'm wrong. Never mind. I'm sorry for the noise.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.