On Mon, Jan 12, 2009 at 10:16:38PM +0000, brian m. carlson wrote: > On Mon, Jan 12, 2009 at 10:02:41PM +0000, Colin Watson wrote: > >On Mon, Jan 12, 2009 at 09:13:15PM +0000, brian m. carlson wrote: > >> fp = (FILE *) 0x0 > > > >That would happen if popen() fails. The manual page says: > > > > The popen() function returns NULL if the fork(2) or pipe(2) > > calls fail, or if it cannot allocate memory. > > > >This could happen if you've run out of memory or hit a resource limit. > >Could you please investigate and find out whether one of these things is > >true? strace may help. > > I determined that the bug is actually in glibc in experimental. The > errno value is set to ENOSYS. Last time I checked, Linux 2.6.27 had > working fork(2) and pipe(2) calls, so glibc is doing some pretty > crackful things. > > I also found out that this is not occuring with every popen call, but > only some of them. Whether the bug occurs is specific to an invocation, > but every such invocation is reproducible. > > Nevertheless, putty should check the return value of popen. Crashing > when popen fails is not exactly robust.
Well, it might well have to bail out anyway, but you're right that it shouldn't segfault. For pu...@projects: there are two unchecked popen calls in unix/uxnoise.c, which caused a segfault in this bug report when popen failed (in this case due to a glibc bug as mentioned, but popen could fail due to resource limits). Could you check them and do something better? Since this is in noise generation, I didn't know whether you wanted to bail out or carry on if you have insufficient entropy, so I haven't attempted to supply a patch. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
