On Fri, 21 May 2010 16:56:49 +0200, Dan Goodman <[email protected]> wrote: > On 21/05/2010 12:55, Andreas Kloeckner wrote: > > On Wed, 19 May 2010 17:22:03 +0200, Dan Goodman<[email protected]> wrote: > >> Hi Andreas, > >> > >> Sorry about posting that overly large file strace.txt to the list - > >> hadn't noticed it was so big. I think I sent a copy directly to you too > >> so that if you want to take a look you can do so? > > > > I got it, though it crashed my email client, and so it took a while > > until I had the motivation to dig it out of my raw email files. But I > > finally did, and it's been pretty informative, I think. > > > > Everything seems to be going normally until nvcc spawns a copy of (I > > think) gcc as pid 26628, which then dies after > > > > [pid 26628] write(1, "*asm:\n%{v:-V} %{Qy:} %{!Qn:-Qy} "..., 4935) = -1 > > EBADF (Bad file descriptor) > > > > Immediately after that, 26627 (an nvcc instance) goes into an infinite > > read loop, because it apparently can't believe that it got nothing back > > From gcc. (i.e. that's an nvcc bug) My guess at what's wrong here starts > > a bit earlier though. It seems that nvcc unconditionally closes fd 0 and > > 1 before spawning gcc, on the assumption that those are > > stdin/stdout. That doesn't appear to be the case, because open returns > > '0' a few times, which indicates to me that stdin/stdout aren't open any > > more by that time. The solution would thus be for you to open some > > 'fake' stdin and stdout files at the start of your spawned > > process. (/dev/null?) > > So, yes indeed that solves the problem. For the moment at > least, we can put something in our code that just redirects stdin/out to > null. Is this something that could be addressed in pycuda or is it an > unavoidable thing given the nvcc bug? Perhaps we should let them know > about it, in that case.
If you could file a bug report with Nvidia about nvcc unconditionally closing fds 0/1, I think that would be the most helpful. Then you can keep your workaround for as long as it's needed, and the problem will eventually (hopefully) vanish. Addressing this PyCUDA is a bit weird, because it adds an extra layer of non-portable cruft. Out of curiosity--how do you detect if an FD is open on Linux/Unix? Andreas PS: Please keep the list cc'd.
pgpYCKkXh79ME.pgp
Description: PGP signature
_______________________________________________ PyCUDA mailing list [email protected] http://lists.tiker.net/listinfo/pycuda
