При проверке пакета kde4libs=4.4.5-alt2 от непривилегированного пользователя происходит segfault: $ rpm -V kde4libs zsh: segmentation fault rpm -V kde4libs (gdb) bt #0 0xb7e57980 in strcmp () from /lib/libc.so.6 #1 0xb7da8904 in hashEqualityString () from /usr/lib/librpmdb-4.0.4.so #2 0xb7da8945 in htGetEntry () from /usr/lib/librpmdb-4.0.4.so #3 0xb7f792f0 in ?? () from /usr/lib/librpm-4.0.4.so #4 0xb7f7a3c1 in ?? () from /usr/lib/librpm-4.0.4.so #5 0xb7f7a727 in ?? () from /usr/lib/librpm-4.0.4.so #6 0xb7f7a8af in rpmdepCheck () from /usr/lib/librpm-4.0.4.so #7 0xb7fa2466 in ?? () from /usr/lib/librpm-4.0.4.so #8 0xb7fa3bbb in showVerifyPackage () from /usr/lib/librpm-4.0.4.so #9 0xb7f8e797 in showMatches () from /usr/lib/librpm-4.0.4.so #10 0xb7f902ae in rpmQueryVerify () from /usr/lib/librpm-4.0.4.so #11 0xb7fa23ab in rpmVerify () from /usr/lib/librpm-4.0.4.so #12 0x08049ee0 in rpmReadConfigFiles () #13 0x0804c440 in ?? () #14 0xb7dfdc66 in __libc_start_main () from /lib/libc.so.6 #15 0x08049301 in rpmReadConfigFiles () (gdb) При запуске этой проверки от root, верификация проходит нормально.
В этом же месте оно падает при попытках apt-get dist-upgrade, apt-get install kde4libs и rpm -U kde4libs.rpm
hsh --init && hsh-install kde4libs у меня не падают ни на i586, ни на x86-64. hsh-run rpm -V kde4libs тоже не падает. Давайте найдём ещё какую-нибудь зацепку.
Система занимает 2 Гб, могу почистить в несколько раз, видимо :)
Жаль, даже полный список пакетов, переустановленный в хэшер с теми же версиями, не помог воспроизвести.
Ну в общем это явно порченная какими-то прежними действиями база, баг легко повторяется прямо из hsh-shell с rpm --dbpath, указывающим на порченную базу. После удаления из тестовой системы нескольких пачек пакетов падение продолжалось, а после ещё нескольких пачек прекратилось. Если из системы удалить только те пакеты, после которых падение прекратилось, оно, разумеется, не прекращается. Так что лично я страдать ерундой прекращаю, а если хочется баг не починить, а воспроизвести с нуля - я пас.
(In reply to comment #5) > Ну в общем это явно порченная какими-то прежними действиями база, баг легко > повторяется прямо из hsh-shell с rpm --dbpath, указывающим на порченную базу. Если rpmdb испорчена, то rpm может вести себя неадекватно. Если бы это был единичный случай, то можно было бы всё свалить на локальную порчу rpmdb, но ведь проблема воспроизводилась одновременно у нескольких человек с разным набором установленных пакетов. > После удаления из тестовой системы нескольких пачек пакетов падение > продолжалось, а после ещё нескольких пачек прекратилось. Если из системы > удалить только те пакеты, после которых падение прекратилось, оно, разумеется, > не прекращается. Я правильно понял, что после того, как падение прекращалось, возвращение пакетов не возобновляло падение?
(В ответ на комментарий №6) > > После удаления из тестовой системы нескольких пачек пакетов падение > > продолжалось, а после ещё нескольких пачек прекратилось. Если из системы > > удалить только те пакеты, после которых падение прекратилось, оно, разумеется, > > не прекращается. > Я правильно понял, что после того, как падение прекращалось, возвращение > пакетов не возобновляло падение? Я не пробовал, я сразу откатил чрут.
(В ответ на комментарий №6) > Я правильно понял, что после того, как падение прекращалось, возвращение > пакетов не возобновляло падение? Возобновляет.
Created attachment 4483 [details] Conflictname, с которым падает
Тут стек с дебагом просят, вот он. (gdb) bt #0 0x4efa1980 in strcmp () from /lib/libc.so.6 #1 0xb7f588e5 in hashEqualityString (key1=0xb7cded0c, key2=0x80cea2c) at rpmhash.c:54 #2 0xb7f588b8 in findBucket (ht=0x80c4a50, key=0x80cea2c) at rpmhash.c:46 #3 0xb7f58be5 in htGetEntry (ht=0x80c4a50, key=0x80cea2c, data=0xbfffda40, dataCount=0x0, tableKey=0x0) at rpmhash.c:139 #4 0xb7fa4031 in dbSatisfiesDepend (ts=0x80c41b8, dbProvCache=0x80c4a50, keyName=0x80cea2c "kde4libs", keyEVR=0x80cea35 "4.0.81", keyFlags=2) at depends.c:490 #5 0xb7fa42f3 in tsSatisfiesDepend (ts=0x80c41b8, dbProvCache=0x80c4a50, keyType=0xb7fd3f32 "Conflicts", keyDepend=0x8113ad0 "C kde4libs < 4.0.81", keyName=0x80cea2c "kde4libs", keyEVR=0x80cea35 "4.0.81", keyFlags=2) at depends.c:571 #6 0xb7fa49aa in checkPackageDeps (ts=0x80c41b8, psp=0x80848c8, dbProvCache=0x80c4a50, h=0x8178650, keyName=0x80b12ea "kde4libs") at depends.c:691 #7 0xb7fa4d2f in checkDependent (ts=0x80c41b8, psp=0x80848c8, dbProvCache=0x80c4a50, tag=RPMTAG_CONFLICTNAME, key=0x80b12ea "kde4libs") at depends.c:752 #8 0xb7fa4eb2 in rpmdepCheck (ts=0x80c41b8, conflicts=0xbfffdc74, numConflicts=0xbfffdc70) at depends.c:796 #9 0xb7fd361c in verifyDependencies (rpmdb=0x8055eb8, h=0x80c3a48) at verify.c:471 #10 0xb7fd397e in showVerifyPackage (qva=0x804c460, rpmdb=0x8055eb8, h=0x80c3a48) at verify.c:534 #11 0xb7fbda2e in showMatches (qva=0x804c460, mi=0x8088e10, showPackage=0xb7fd38a5 <showVerifyPackage>) at query.c:551 #12 0xb7fbf2a4 in rpmQueryVerify (qva=0x804c460, source=RPMQV_PACKAGE, arg=0xbffff1ec "kde4libs", rpmdb=0x8055eb8, showPackage=0xb7fd38a5 <showVerifyPackage>) at query.c:1019 #13 0xb7fd3ab2 in rpmVerify (qva=0x804c460, source=RPMQV_PACKAGE, arg=0xbffff1ec "kde4libs") at verify.c:567 #14 0x08049f96 in main (argc=5, argv=0xbfffef94) at rpmqv.c:1146
key1=0xb7cded0c в 1-м фрейме это мусор. Для истории: librpm-4.0.4-alt98.39
(В ответ на комментарий №11) > key1=0xb7cded0c в 1-м фрейме это мусор. Впрочем, это написано по памяти и может быть неправдой.
rpm-4.0.4-alt98.40 -> sisyphus: * Thu Aug 05 2010 Alexey Tourbin <at@altlinux> 4.0.4-alt98.40 - build/files.c (parseForSimple): Fix potential NULL pointer dereference (Dmitry V. Levin, ALT#23813). - depends.c (dbSatisfiesDepend): Use strdup for dbProvCache keys to avoid dangling pointers (ALT#23811).
Подтверждаю, починилось на прежней базе.
