On Aug 24, 2008, at 10:27 AM, Alexey Tourbin wrote:
> This code is subject to infinite loop.
> Consider how it is called:
> mi = rpmdbInitIterator(db, RPMDBI_PACKAGES, hdrNum, sizeof(hdrNum));
> h = rpmdbNextIterator(mi);
> and consider that the header indentified with hdrNum is damaged.
> What happens then? In line 2536, you "goto top". And on top,
> mi->mi_set is epmty (because it is not index-to-join-key lookup),
> and key->data is hdrNum. This means that dbiGet gets called with
> DB_SET, you get the same header which is damaged etc.
> (I'll try to fix this but I'm not sure what's the best way to fix
> this yet.)
Yup, been there for years.
I'm not sure the best fix either, which is why not fixed. The failure
is really annoying, infinite loop with signals blocked, only kill -9
window can stop the spewage.
Likely adding a layer of persistence to not repeat a lookup that
was previously known to fail using a, say, 10 deep LRU array,
would address the infinite loop symptom.
Another symptom fix would be to add a hdrNum blacklist, never
looking up any headers in blacklist. When fixing severely damaged
rpmdb's, I often compile in a blacklist check in order to achieve a
The real fix is much deeper, understanding why the header number
got damaged in the 1st place. Fixing the symptom will only make
achieving a real fix very much harder.
73 de Jeff
Received on Sun Aug 24 16:39:10 2008