I tried to revert the rpmdb/legacy.c back to 5.3, 5.2. and 5.1 versions.  They
all have the same issue.

I attempted the same within the prelink side of things, and as far as I can tell
the code for writing to stdout for RPM validation hasn't changed in about 5 
years.

So I'm at a bit of a loss to explain whats wrong, and why it suddenly happened. 
 :(

--Mark

On 2/25/11 6:07 PM, Mark Hatle wrote:
> On 2/25/11 5:53 PM, Jeff Johnson wrote:
>>
>> On Feb 25, 2011, at 6:27 PM, Mark Hatle wrote:
>>
>>> On 2/25/11 8:40 AM, Mark Hatle wrote:
>>>> On 2/24/11 10:41 PM, Jeff Johnson wrote:
>>>>>
>>>>> On Feb 24, 2011, at 11:14 PM, Mark Hatle wrote:
>>>>>
>>>>>> I'm trying to validate prelinked binaries and I'm getting a somewhat 
>>>>>> strange result:
>>>>>>
>>>>>> ........    /bin
>>>>>> S.?.....    /bin/bash
>>>>>> ........    /bin/bashbug
>>>
>>> Ok, I've done more digging.  If I run this within gdb, I'm suddenly seeing 
>>> an
>>> error message appear on the screen:
>>>
>>> prelink: Couldn't write file to standard output: Broken pipe
>>> S.?..... <filename>
>>>
>>> However, if I use gdb and step through the fork/exec in rpmdb/legacy.c at 
>>> around
>>> like 128..  I don't get the error message -- and it comes back with a "." 
>>> for a
>>> valid md5um.  (If I run this without GDB, I get the '?' and no error message
>>> from prelink.)
>>>
>>> So it looks like we have some type of pipe issue.
>>>
>>> Any suggestions?
>>>
>>
>> Hmmm ... that sounds like racy or signal delivery to me ... parent
>> is AWOL when prelink is trying to write to the stdout pipe fdno
>> leading to EPIPE.
>>
>> (aisde, basis for guessing "racy")
>> getOutputFrom() has always been racy. mostly fixed @rpm.org too,
>> I'll swipe the code one of these days.
>>
>> But the select/poll delay is sufficient to get the child plugged
>> onto the pipe @rpm5.org. been "gud enuf" for years in rpmbuild but the
>> code is pathetic.
>>
>> (back to running prelink undo onto a pipe)
>>
>> OK, legacy.c is classic fork/exec. Kinda hard to break something
>> there, but won't be the first time I've screwed a fork/exec somehow.
> 
> Ya, I looked at this and don't see an obvious race...
> 
>> About all that's new/different in legacy.c is the yarnLock()'s I added to try
>> to protect the static lazily allocated cmd strings while getting up
>> to speed on DRD/Helgrind tools in valgrind.
> 
> I doubt that is the issue as well..
> 
>> My test case was
>>      rpm --Va
>> so prelink undo (and the legacy.c code changes) was exercised
>> pretty thoroughly.
>>
>> You might want to diff legacy.c against 5.2.1 or 5.1.9 just to see if
>> I screwed up in 5.4.0 somehow. There really hasn'nt been any changes
>> to legacy.c for a L-O-N-G time, all the code is destined for the
>> bit bucket somewhen (and prelink undo will eventually become a
>> dlopen() module toed into a --verify framework). But there's
>> zero interest in changing anything in RPM so I haven't bothered.
> 
> I'll run a diff and see what I get, but this doesn't look any different (then
> the yarn locks) since the last time I looked at this code a few years ago.
> 
>> Perhaps a stricter interlocked parent <-> child startup is needed
>> (though I don't see why reading code). But linux is known to
>> run child before parent which might get tricky. Anyways opening
>> _ANOTHER_ pipe and having the child block on a read() until
>> the parent starts running and closes the other end of the pipe
>> (wherein child returns from read with 0b aka an EOF) could be attempted.
>>
>> Still -- the only state in the fork/exec is in pipes[2] and the fdno return.
>>
>> I sure don't see what else is needed.
> 
> Ya, it doesn't LOOK like there should be a problem.. but I'll run some diffs 
> and
> see.
> 
> --Mark
> 
>> Does prelink outside of rpm Just Work or not? If standalone
>> prelink Just Works then I broke rpm-5.4.0 in some fashion that
>> I cannot see. Try going back to legacy.c from rpm-5.2.1 is about
>> all I can think of to get _SOMETHING_ working and then staring at the diff
>> and/or bisecting back until its obvious what is wrong is all I can think of.
>>
>> hth
>>
>> 73 de Jeff
> 
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to