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
