| Summary: | Segmentation Fault when installing or removing a package | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Florent Le Coz <louiz> | ||||||
| Component: | rpm | Assignee: | Fedora Packaging Toolset Team <packaging-team> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 17 | CC: | bugzilla.acct, ffesti, jnovy, packaging-team, pknirsch, pmatilai | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-07-02 11:18:47 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
Even without debuginfo packages, the traceback does tell the rough whereabouts of the crash: it appears to crash while looking up pubkeys from the rpmdb. Could be a damaged index, but optimally rpm should handle that more gracefully than segfault. Please tar up the contents of /var/lib/rpm (after removing the __db* files) and put it someplace where I can grab it for inspection. If you dont have a suitable web/ftp site to put it to, attach here. Once the db is backed up, 'rpmdb --rebuilddb' should bring it back to life if it's a case of a damaged index. I tar’d the content of /var/lib/rpm here: http://buddycloud.poezio.eu/things/rpmdb.tar.xz But even after a rpmdb --rebuilddb, rpm still crashes. (I also tried rm -rf /var/lib/rpm; rpmdb --rebuilddb, does not solve the issue either) And the gdb traceback is exactly the same. Apart from this (which is of course not normal) on ncurses-base package, I dont see any crashes when operating on that db: error: rpmdbNextIterator: skipping h# 659 Header V3 RSA/SHA256 Signature, key ID 1aca3465: BAD Looking at the db contents I'd guess this system has been upgraded from an earlier version to F17, right? In that case /usrmove conversion has taken place and its possible that might've messed up something. When did the crashing start, after some yum update or .. other special events? Since 'rpm -qa' works its quite likely that verify works, which should be able to point out if there are damaged files or such. See if 'rpm -Vavv' works and if so, attach the whole entire output here (eg 'rpm -Vavv &> /tmp/rpm-verify.txt' and attach the resulting /tmp/rpm-verify.txt, this will take quite a while). Oh and btw, to get a proper traceback you can download the relevant debuginfo packages manually and use rpm2cpio to get the files in place. Created attachment 580137 [details]
gdb traceback of rpm -vih, with rpm debuginfo package.
Thanks for the traceback, it does give more insight to what's going on: it's crashing trying to open a cursor on the package name index. It's just that what happens there looks like largely a "can't happen" case, and I can't reproduce the crash with that db even when taken to an actual F17 system. In other words, it doesn't look like a regular bug but something "circumstancial", such as other damage to the system / libraries. How and when did this problem start? (Sorry about the long delay). I could not stand to have a non-working workstation so I finally completely reinstalled fedora on my machine… And the problem disappeared. But it turns out that I had a broken ram… Even gcc or firefox were sometimes segfaulting for no reason. Replacing my ram solved all of these problems, so this bug was an hardware failure only. That’s not a bug, it can be closed. And sorry about the disturbance. Right. I should've thought to ask whether it always crashes with the same traceback (almost certainly not the case when hw failure is involved), got fooled to the "previously working hardware started acting up after upgrade" side-track. Nobody expects *their* hardware to suddenly fail (been there, done that :) Thanks for letting us know. That bug was caused (as far as I can tell) only by a defective hardware (RAM in my case). I then doubt this is related to any other bug. (unless, of course, your RAM is broken as well) |
Created attachment 578622 [details] gdb traceback of rpm -vih Description of problem: RPM fails with a segmentation fault whenever I try to install or remove a package (through yum or directly using the rpm command). It does not fail for other queries, for example rpm -qa works as expected. Version-Release number of selected component (if applicable): rpm-libs-4.9.1.3-1.fc17.x86_64 rpm-build-4.9.1.3-1.fc17.x86_64 rpm-4.9.1.3-1.fc17.x86_64 rpm-build-libs-4.9.1.3-1.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. rpm -vih ./some_package.rpm Actual results: Crash Expected results: Should install the package Additional info: rm -f /var/lib/rpm/__db.* does not solve anything Attached a gdb traceback, but since I’m missing the debug packages (which I cannot install, due to that bug) I don’t know if it will be really helpful.