tyring to update http://koji.fedoraproject.org/koji/buildinfo?buildID=461253 in the x86_64 version results in a segfault in yum, i guess this must never happen independet what is wrong with the package [99020.567527] yum[17561]: segfault at 0 ip 00007f4e506a2551 sp 00007ffffe765288 error 4 in libc-2.16.so[7f4e50542000+1ad000] Loaded plugins: etckeeper, presto, protectbase, tsflags Examining firefox-23.0.1-4.fc18.x86_64.rpm: firefox-23.0.1-4.fc18.x86_64 Marking firefox-23.0.1-4.fc18.x86_64.rpm as an update to firefox-23.0.1-3.fc18.x86_64 Resolving Dependencies --> Running transaction check ---> Package firefox.x86_64 0:23.0.1-3.fc18 will be updated ---> Package firefox.x86_64 0:23.0.1-4.fc18 will be an update --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies Dependencies Resolved =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Updating: firefox x86_64 23.0.1-4.fc18 /firefox-23.0.1-4.fc18.x86_64 33 M Transaction Summary =================================================================================================================================================================================================================== Upgrade 1 Package Total size: 33 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction etckeeper: pre transaction commit Segmentation fault
sorry, forgot possible relevant infos [root@srv-rhsoft:~]$ rpm -q yum yum-3.4.3-54.fc18.noarch [root@srv-rhsoft:~]$ rpm -q rpm rpm-4.10.3.1-2.fc18.x86_64 [root@srv-rhsoft:~]$ rpm -q glibc glibc-2.16-34.fc18.x86_64
Traceback please.
Created attachment 794675 [details] strace output result of "strace rpm -Uvh firefox-23.0.1-4.fc18.x86_64.rpm 2>> strace.log >> strace.log" the interesting is taht rpm/yum works at all and only this package is affected
strace can be useful too but its not a traceback... this is what I'm after: http://fedoraproject.org/wiki/StackTraces
...but nevermind, I can actually reproduce the crash with that package so no need for you to produce a full traceback.
well *did you* try it with the listed RPM/GLIBC vesions and *exactly* this package? Aug 26 14:18:42 Updated: rpm-4.10.3.1-2.fc18.x86_64 [root@srv-rhsoft:~]$ cat yum.log | grep "Sep " | wc -l 62 indicates that the package itself is broken adn rpm should handle that better [root@srv-rhsoft:/var/cache/yum/updates-testing/packages]$ gdb rpm GNU gdb (GDB) Fedora (7.5.1-41.fc18) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/rpm...Reading symbols from /usr/lib/debug/bin/rpm.debug...done. done. (gdb) run -Uvh firefox-23.0.1-4.fc18.x86_64.rpm Starting program: /usr/bin/rpm -Uvh firefox-23.0.1-4.fc18.x86_64.rpm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38 38 movdqu (%rdi), %xmm1 Missing separate debuginfos, use: debuginfo-install libattr-2.4.46-7.fc18.x86_64 libgomp-4.7.2-8.fc18.x86_64 nspr-4.10.0-3.fc18.x86_64 nss-softokn-3.15.1-1.fc18.x86_64 nss-softokn-freebl-3.15.1-1.fc18.x86_64 nss-util-3.15.1-1.fc18.x86_64 pcre-8.31-5.fc18.x86_64 sqlite-3.7.13-2.fc18.x86_64 xz-libs-5.1.2-2alpha.fc18.20130729.rh.x86_64 zlib-1.2.7-9.fc18.20130729.rh.x86_64 (gdb)
> ...but nevermind, I can actually reproduce the crash > with that package so no need for you to produce a > full traceback well, that is what i would expect as first action in any case before ask debug-infos from users and only after that does not reproduce the problem a NEEDINFO
Quite often a segfault can only be produced in very specific conditions on a local system (and this smelled like one of those cases but turned out it is not), and those conditions can go away in which case the information about a crash might be forever lost or extremely hard to reproduce. Asking for a traceback upfront is an insurance against that. P.S. FWIW the info in comment #6 is quite useless, you'd have run 'bt' from the gdb prompt to get the actual backtrace.
> Quite often a segfault can only be produced... agreed, but the first step IMHO should be look if it is the case > P.S. FWIW the info in comment #6 is quite useless, you'd > have run 'bt' from the gdb prompt to get the actual backtrace i stopped more because it requested a ton of another debug-packages while the 12 before was around 200 MB and pretty sure after that it would have requested the next iteration......
Okay the problem is a %pretrans -p <lua> scriptlet without a body. Generally scriptlets are permitted to omit body when the "interpreter" specified via -p does the necessary things on its own (such as /sbin/ldconfig) but a -p <lua> script with no body makes no sense whatsoever (so there's a packaging bug involved too). Of course rpm should not create such packages in the first place, nor crash if it encounters one so. Anyway, fill fix, thanks for reporting.
Fixed upstream: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=5f3598a700e8e028f9140682262869ca319597ee
*** Bug 1005425 has been marked as a duplicate of this bug. ***
*** Bug 1005253 has been marked as a duplicate of this bug. ***
rpm-4.10.3.1-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/rpm-4.10.3.1-3.fc18
rpm-4.11.1-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/rpm-4.11.1-7.fc20
rpm-4.11.1-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/rpm-4.11.1-2.fc19
Package rpm-4.10.3.1-3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpm-4.10.3.1-3.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16211/rpm-4.10.3.1-3.fc18 then log in and leave karma (feedback).
rpm-4.11.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
rpm-4.10.3.1-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
rpm-4.11.1-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1005605 has been marked as a duplicate of this bug. ***