On Aug 27, 2008, at 12:26 PM, Alexey Tourbin wrote:

> On Wed, Aug 27, 2008 at 09:16:50AM -0400, Jeff Johnson wrote:
>>>
>> Nice catch! Changing RPM_MIN_TYPE back to 1 is the obvious fix.
>>
>> However, I do wonder why this has not been reported before. AFAICT
>> the issue should have been very very loud and obvious.
>
> This apparently means that rpm5 is not that widely used.
> Perhaps you should call for yet more major distributions.
>

I'd agree that rpm5 is not widely used on "legacy" distributions.

I'm more interested in best possible engineering than with
widest possible usage atm for rpm-5.x. Better engineering
will eventually be adopted is my guess, and I most definitely
do not want the burden of support for rpm everywhere, I'm
just one guy who wants his life back.

Meanwhile changing RPM_MIN_TYPE was quite consciously done
(by me last fall) in order to switch from RPM_CHAR_TYPE to
RPM_UINT8_TYPE. From a design POV, rpm doesn't need
or use the data types it has very intelligently. Type coercion, not
stronger data typing, is the forward looking feature goal.

But its likely trivial to change RPM_MIN_TYPE back to 1 (but see below).

>> What was the full calling context where the problem was seen?
>
> It goes like this:
>
> $ ./rpm -q -vvv --whatprovides /a
> D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
> D: locked   db index       /var/lib/rpm/Packages
> D: opening  db index       /var/lib/rpm/Basenames rdonly mode=0x0
> error: rpmdb: damaged header #625 retrieved -- skipping.
> error: rpmdb: damaged header #625 retrieved -- skipping.
> D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
> file /a: No such file or directory
> D: closed   db index       /var/lib/rpm/Providename
> D: closed   db index       /var/lib/rpm/Basenames
> D: closed   db index       /var/lib/rpm/Packages
> $ ./rpm -q -vvv --whatprovides /bin/cat
> D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
> D: locked   db index       /var/lib/rpm/Packages
> D: opening  db index       /var/lib/rpm/Basenames rdonly mode=0x0
> error: rpmdb: damaged header #90 retrieved -- skipping.
> error: rpmdb: damaged header #90 retrieved -- skipping.
> error: rpmdb: damaged header #531 retrieved -- skipping.
> error: rpmdb: damaged header #585 retrieved -- skipping.
> error: rpmdb: damaged header #1101 retrieved -- skipping.
> error: rpmdb: damaged header #1173 retrieved -- skipping.
> D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
> file /bin/cat is not owned by any package
> D: closed   db index       /var/lib/rpm/Providename
> D: closed   db index       /var/lib/rpm/Basenames
> D: closed   db index       /var/lib/rpm/Packages
> $
>
> (I don't know why --whatprovides is special; simple -q queries
> whithout join-key lookup work fine.)
>

Hmmm, there is nothing special abt --whatprovides that should wander
into code that depends on RPM_MIN_TYPE (unless I'm missing something).

RPMTAG_FILESTATES is the only tag that was ever type'd as RPM_CHAR_TYPE
iirc. And here are the uses, none of the code is directly on a query  
code path (this is HEAD):

[jbj@wellfleet lib]$ grep FILESTATE *.c
psm.c:  he->tag = RPMTAG_FILESTATES;
psm.c:  he->tag = RPMTAG_FILESTATES;
rpmfi.c:    _fdupedata(h, RPMTAG_FILESTATES, fi->fstates);
transaction.c:    he->tag = RPMTAG_FILESTATES;

Ah, perhaps its a rpmfiNew() call that triggers the RPMTAG_FILESTATES  
access ...
checking ... not seeing the problem yet, but a rpmfiNew() call is the  
likely culprit.

> Actually it was an infinite loop with ever increasing mi->mi_setx
> and all signals blocked, so I thought that first I had to fix that
> infinite loop.  And then it was some printf-style debugging; the
> surprising thing is that printf debuggins sometimes goes faster than
> gdb breakpoints etc.

Yes, printf's are way easier than gdb for large complicated stateful  
issues.

And the infinite loop with signals blocked is most annoying.

73 de Jeff