On Feb 26, 2011, at 12:27 PM, pinto.e...@gmail.com wrote: > Perhaps a waitpid could be better in the parent after the fork ? Just a guess > .
That cannot be done because its a stream from a helper that is needed to impedance match into the existing --verify implementation. But prelinking is all an exquisitely subtle hack (which arguably has nothing to do with "package management") that needs to be improved upon and generalized to handle "verification" opaquely. SELinux xattr's and file capabilities and Tresys "collections" and MSSF Aegis are all other candidates for opaque modular (through dlopen) "verification" as well as prelinking. But that work needs some ROADMAP interest to even begin, of which there is none visible. Catching SIGCHLD, not waitpid, is a bit more general an implementation if/when RPM starts to move more forecefully and deliberately to multi-threading because its asynchronous (like exceptions are). Note that I have no love of SIGCHLD or signals; the grotesque use of POSIX mutexes to clock a signal event onto a thread was driven by a @redhat build system implementation way back when, which decided to put ALL of rpm-python (and rpmlib) on a separate thread, and then screamed "RPM is b0rken!" so loudly that I stuffed the deep dark chocolate POSIX mutexes up their noses. SIGCHLD is most definitely sent to the main process, not the thread, for reasons that have nothing to do with "package management". Otherwise yes: waitpid is obvious KISS. The reaping is surely there someplace, just I've forgotten where (like 7+ years later without any bug reports of consequence like here). But I'm sure I figgered a way to reap the prelink undo helper to avoid the "support" issue when enquiring FL/OSS developing minds want to know why rpm --verify has dozens of zombies attached. 73 de Jeff > -----Original Message----- > From: Jeff Johnson > Sent: 26/02/2011, 07:43 > To: rpm-devel@rpm5.org > Subject: Re: prelinked binaries failing validation > > > > On Feb 26, 2011, at 1:21 AM, Jeff Johnson wrote: > >> >> On Feb 26, 2011, at 1:12 AM, Mark Hatle wrote: >> >>> 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. >>> >> >> And rpmdb/legacy.c hasn't changed meaningfully (afaik) in 5+ years either. >> >>> So I'm at a bit of a loss to explain whats wrong, and why it suddenly >>> happened. :( >>> >> >> Then its time to vary something else. >> >> Is the problem all platform or specific to this platform? >> >> Does the problem exist with rpm-5.3.x (also "RPM ACID") >> or rpm-5.1.9 (which will need dbconvert.sh run)? >> > > This is the only bracketing of the problem reported: > >> 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.) > > Heisenbug's that disappear with gdb single stepping are timing/racy usually. > > Salt in some nanosleep's and see what happens. My guess is that the > child is running before the parent, so add a sleep(5) after > the fork before the exec. > > 73 de Jeff > > > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
