Stephen Smoogen writes:
»My apologies for bad quoting.. email from phone. What version of rpm build is used and what are some packages which are rebuilt that show this issue. This may be needed if the core dump is due to something else in the environment like memory limits etc
It's 4.19.1 on FC39, and it's packages that I'm working on. It's glibc complaining about a double-free, and not any resource limits. I can get a backtrace out of it:
#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)
I am looking at this core dump. I see 32 active execution threads at the
time this whole thing went kaput, and all the code in rpmug.c is definitely
not thread safe. I did not look very hard, I don't know if there are mutexes
higher up the call chain, but the overall behavior – occasional core dumps
-- is indicative of thread races.
Attachment:
pgpTFP_nMaO5M.pgp
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
