On Nov 11, 2009, at 5:58 PM, Per Øyvind Karlsen wrote:
Do you have a reproducer for whatever prompted this change?
--> fd 0xb4a3c30 ++ 4 Fclose at rpmio.c:2464| LIBIO
0xb4a11f0(-1) fdno -1 | LZD 0xb4e36b8 fdno 9 | UFD -1 fp (nil)
==> xzdClose(0xb4a3c30) rc 0| LIBIO 0xb4a1
2009/11/12 Jeff Johnson
>
> On Nov 11, 2009, at 5:58 PM, Per Øyvind Karlsen wrote:
>
> Hmmm ...
>
>
>
>> Happened with:
>> [r...@localhost rpm-5.2.DEVEL]# valgrind --track-origins=yes .libs/rpm
>> --rpmiodebug -Uvh --force
>> ~peroyvind/lib64directfb1.4_0-1.4.2-2mdv2010.1.x86_64.rpm
>>
>>
> Got
On Nov 11, 2009, at 5:58 PM, Per Øyvind Karlsen wrote:
Hmmm ...
Happened with:
[r...@localhost rpm-5.2.DEVEL]# valgrind --track-origins=yes .libs/
rpm --rpmiodebug -Uvh --force ~peroyvind/
lib64directfb1.4_0-1.4.2-2mdv2010.1.x86_64.rpm
Got a pointer to the package? IMHO its likelier th
On Nov 11, 2009, at 5:36 PM, Jeff Johnson wrote:
Hmmm, careful here, Fclose() is the twistiest
piece of code in RPM, hands down.
And I can tell you why the code was written this way.
There's a debugging message that also prints the
fdno on top of stack tied to fdFree().
By doing the pop be
2009/11/11 Jeff Johnson
> Hmmm, careful here, Fclose() is the twistiest
>
> piece of code in RPM, hands down.
>
> For starters, fdFree() doesn't really free anything,
> but rather decrements a reference count, and returns
> the same fd pointer. If fdPop() is getting a NULL
> pointer, then a refco
Hmmm, careful here, Fclose() is the twistiest
piece of code in RPM, hands down.
For starters, fdFree() doesn't really free anything,
but rather decrements a reference count, and returns
the same fd pointer. If fdPop() is getting a NULL
pointer, then a refcount, likely on an error pathway,
has gon
2009/11/11 Jeff Johnson
> This likely should be perhaps 4 or so. 60 is way too long.
>
> The "heavily loaded" is really a red herring. Any modern kernel
> on any reasonably configured linux box should easily be able to
> satisfy a read request in much much less than 60 seconds.
>
> The original i
This likely should be perhaps 4 or so. 60 is way too long.
The "heavily loaded" is really a red herring. Any modern kernel
on any reasonably configured linux box should easily be able to
satisfy a read request in much much less than 60 seconds.
The original intent of the timeout was to deal with
