rpm-5.4.10-22.i686 loops forever when installing ntpd-4.2.6p5-5.i686.rpm

[Jeffrey Johnson]

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