Summary: | rpm сегфолтится на верификации пакета kde4libs = 4.4.5-alt2 | ||||||
---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Konstantin Pavlov <thresh> | ||||
Component: | rpm | Assignee: | placeholder <placeholder> | ||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
Severity: | major | ||||||
Priority: | P3 | CC: | aen, at, glebfm, icesik, imz, ldv, php-coder, placeholder, real.altlinux.org, vt, wrar | ||||
Version: | unstable | ||||||
Hardware: | x86 | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Konstantin Pavlov
2010-07-26 13:30:33 MSD
В этом же месте оно падает при попытках 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). Подтверждаю, починилось на прежней базе. |