Segfault during transaction doing dnf update
#1949
Labels
Priority: HIGH
Triaged
Someone on the DNF 5 team has read the issue and determined the next steps to take
Comments
|
When updating firefox, these are the last lines in the log file: So it appears it is crashing when running the pre-transaction scriptlet when trying to update the progress bar, because that progress bar hasn't been created yet I guess. |
|
Yes, the active_progress_bar field of dnf5::RpmTransCB defaults to NULL and DNF5 code needs to explicitly initialize it with new_progress_bar() method. So probably somewhere the initialization is missing. Or we should guard all dereferences of active_progress_bar with a test on difference from NULL. Unfortunately, I'm not able to reproduce it. If you update the package, does it crash for you all time time? |
|
I am seeing this on two separate machines reliably when I try to do any update that includes Just looking through the code in |
pkratoch
added
the
Triaged
|
Could you please provide more lines of dnf.log when the crash happens. I'd like to see everything from "DEBUG Found running kernel". The problem of a backtrace is that it shows a state while I need to understand how we got to the state. If I cannot reproduce it, "INFO RPM callback" lines of the log could help. But the log you pasted is prematurely cut at the head. Problem is that I hope seeing the whole log helps me understand where is the mistake in callback order. It could be a bug in RPM library calling the pre-transcation script out of order. |
|
I just tried a transaction to update Firefox, and here is the full contents of the |
|
That helps. It shows that "pre-transaction scriptlet" is the very first counted callback in your output, while DNF expected "verify" callback to precede. This what I get when updating alsa-sof-firmware: The two triggering packages, firefox and alsa-sof-firmware, has the distinct feature that they define a pretrans scriptlet which what is reported with "callback start pre-transaction scriptlet" in the log and what is normally printed by DNF as "Prepare transaction" : and that's when your DNF crashes. Do you have disabled transaction checks or some other verifications, like signature checks, in DNF configuration ("tsflags" option) or in RPM configuration? |
|
Ah, yes I do have an RPM setting to disable verification by setting I have older Intel toolchain RPMs installed from their repository, and those are known to have signatures that rpm-sequoia refuses to accept (https://lists.fedoraproject.org/archives/list/[email protected]/message/J2SX6FSIUZHUWBZ3RWB75D4XSNJ367AD/). I guess based on the comment in rpm-software-management/rpm#2351 (comment) I might be able to remove this (if they did rebuild all their older RPMs to have new signatures), but I don't have time to check that anytime soon probably. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While trying to update some packages in Fedora 41, I am reliably getting segfaults. This doesn't seem to happen to every package though, because I was able to run
dnf updateon specific packages and they installed. I am noticing this onalsa-sof-firmware, and also withfirefox.The terminal output is:
When I run dnf5 in GDB with debug symbols, it gives the following backtraces.
For
alsa-sof-firmware:For
firefox:I am using
dnf5-5.2.8.1-1.fc41.x86_64The text was updated successfully, but these errors were encountered: