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.
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.
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.
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.
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
smime.p7s
Description: S/MIME cryptographic signature
