Stephen Smoogen writes:
#1 0x00007f05dd8588ee raise (libc.so.6 +
0x3e8ee)
#2 0x00007f05dd8408ff abort (libc.so.6 + 0x268ff)
#3 0x00007f05dd8417d0 __libc_message.cold (libc.so.6 +
0x277d0)
#4 0x00007f05dd8b47a5 malloc_printerr (libc.so.6 +
0x9a7a5)
#5 0x00007f05dd8b6a3a _int_free (libc.so.6 + 0x9ca3a)
#6 0x00007f05dd8b93de free (libc.so.6 + 0x9f3de)
#7 0x00007f05dda984ec rpmugUid (librpm.so.10 + 0x584ec)
#8 0x00007f05dda84255 rpmfilesStat (librpm.so.10 +
0x44255)
#9 0x00007f05dda8438f rpmfiStat (librpm.so.10 + 0x4438f)
#10 0x00007f05dda84444 rpmfiArchiveWriteHeader (librpm.so.
10 + 0x44444)
#11 0x00007f05dda871c9 iterWriteArchiveNext (librpm.so.10
+ 0x471c9)
Thanks. I was wondering if it was dnf/rpm on the system or dnf/rpm in the
chroot but it sounds like something changed between 4.19.0.1 (what I had on
my system since September?) and 4.19.1 ( December)
Looking at a diff between the 4.19.0 an 4.19.1 tags, a call to rpmfiStat()
was added to fill_archive_entry(). The backtrace above shows the execution
finding its way from rpmfiStat() into very-much-thread-unsafe code in rpmug.c
Further up the backtrace is packageBinaries() which, according to the
backtrace, is being multithreaded via OMP. Looking at the core dump, I see a
bunch of execution threads running packageBinaries().
I'm confident that this is the breakage. 4.19.1 needs to be fixed ASAP.
My humble suggestion for the simplest fix is to slap a __thread on all those
static variables in rpmug.c. Or, perhaps, throw a mutex around them so that
all execution thread share that micro-optimization those static variables
are used for…
Hopefully that's the only thing that's thread unsafe in there…