On Oct 22, 2012, at 4:01 PM, Jeffrey Johnson wrote:
>
> On Oct 22, 2012, at 2:57 PM, Elan Ruusamäe wrote:
>
>> On 10/22/2012 05:58 PM, Jeffrey Johnson wrote:
>>> For a suspected database error in the Conflictname index,
>>> then comparing the outputs with
>>>
>>> /usr/lib/rpm/macros:%_dbi_config_3_Conflictname %{_dbi_btconfig}
>>> %{?_bt_dupsort} debug
>>>
>>> may be informative. The access patterns SHOULD be similar.
>> first one that loops, second one that finishes fine
>>
>> $ rpm -D '_dbi_config_3_Conflictname %{_dbi_btconfig} %{?_bt_dupsort}
>> debug' -ihv ntpd-4.2.6p5-5.i686.rpm --test
>> 2>ntpd-conflictdb-debug-morpheus.txt
>> ^C
>>
>> -> 6.3M
>> http://carme.pld-linux.org/~glen/ntpd-conflictdb-debug-morpheus.txt
>>
And here is the different/broken behavior (see the DB_NEXT_DUP):
<-- db3open(0x9694568,Conflictname,0xbffaad3c) dbi 0x969cb20 rc 0
flags: 0x500<AUTO_COMMIT,RDONLY>
<-- db3associate(0x9694c00(Packages),0x969cb20(Conflictname),0xb75ffe89,0x0) rc
0
flags: 0x0
--> rpmmiInit(0x9694568, Conflictname, 0x969b3a0[0]="config(ntpd)") dbi
0x969cb20 mi 0x9699ce8
--> rpmmiNext(0x9699ce8) dbi 0x969cb20(Conflictname)
<-- db3copen(0x969cb20,(nil),0x9699d04,0x0) dbc 0x969d570 0x0 rc 0
<-- db3cget(0x969cb20,0x969d570,0xbffaad48,0xbffaad80,0x1a) rc -30988
flags: DB_SET
key: 0x969ccc8[12] 0x0 "config(ntpd)"
data: (nil)[0] 0x800<USERMEM>
<-- rpmmiGet(0x969cb20(Conflictname),0x969d570,0xbffaad48,0xbffaad80,0x1a) rc
-30988
--> rpmmiInit(0x9694568, Conflictname, 0x969ab40[0]="ntp") dbi 0x969cb20 mi
0x9699ce8
--> rpmmiNext(0x9699ce8) dbi 0x969cb20(Conflictname)
<-- db3copen(0x969cb20,(nil),0x9699d04,0x0) dbc 0x969d8b0 0x0 rc 0
<-- db3cget(0x969cb20,0x969d8b0,0xbffaad48,0xbffaad80,0x1a) rc -30999
flags: DB_SET
key: 0x969d888[3] 0x0 "ntp"
data: (nil)[10316] 0x800<USERMEM>
<-- db3cpget(0x969cb20,0x969d8b0,0xbffaad48,0xbffaad64,0xbffaad80,0x1a) rc 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This line SHOULD have returned "… rc -30988" (aka DB_NOTFOUND) if machines were
"identical".
============================================================================
flags: DB_SET
key: 0x969d888[3] 0x0 "ntp"
pkey: 0x969d898[4] 0x0 0x000001ab
data: 0xb76f3000[10316] 0x800<USERMEM>
<-- rpmmiGet(0x969cb20(Conflictname),0x969d8b0,0xbffaad48,0xbffaad80,0x1a) rc 0
--> rpmmiNext(0x9699ce8) dbi 0x969cb20(Conflictname)
<-- db3cget(0x969cb20,0x969d8b0,0xbffaad48,0xbffaad80,0x11) rc -30988
flags: DB_NEXT_DUP
key: (nil)[0] 0x0
data: (nil)[0] 0x800<USERMEM>
<-- rpmmiGet(0x969cb20(Conflictname),0x969d8b0,0xbffaad48,0xbffaad80,0x11) rc
-30988
This may be a slightly different manifestation of the DB_BUFFER_SMALL issue in
this thread
(and in archives) but that's just a guess:
http://rpm5.org/community/rpm-devel/5390.html
While bisecting, you need to find the "other" package that has
Provides: ntp
and removing (or otherwise "fixing") will (I claim) provide you
with 2 "working" (and "sufficiently similar") machines. That isn't
a "fix" per se, but does stop the clock on repairing your machine(s).
(aside)
I'm perfectly prepared to drill out the db-5.3.x DB_BUFFER_SMALL issue if/when
I can actually
capture a reproducer on some machine. It will take about a weekend of
adding printf's to find and understand the change in behavior in db-5.3.x
(which isn't very hard, just rather tedious).
The band-aid in use in PLD (and @windriver and in Mandriva/ROSA)
is kinda creepy (imho).
73 de Jeff "I can't fix what I can't see." no matter what
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
