This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients gregory.p.smith, pitrou
Date 2011-01-25.21:55:43
SpamBayes Score 1.824857e-11
Marked as misclassified No
Message-id <1295992544.44.0.542393820985.issue10826@psf.upfronthosting.co.za>
In-reply-to
Content
So, I added some debug info to test_pass_fds:

 -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13}
 -- fds that remained open: {0, 1, 2, 3, 5}
 -- debug info:
0 8194 posix.stat_result(st_mode=8592, st_ino=12582920, st_dev=82051072, st_nlink=1, st_uid=1140, st_gid=7, st_size=0, st_atime=1295990436, st_mtime=1295991135, st_ctime=1295990436)
1 2 posix.stat_result(st_mode=4096, st_ino=79119887, st_dev=84148224, st_nlink=0, st_uid=1140, st_gid=1, st_size=0, st_atime=1295991135, st_mtime=1295991135, st_ctime=1295991135)
2 8194 posix.stat_result(st_mode=8592, st_ino=12582920, st_dev=82051072, st_nlink=1, st_uid=1140, st_gid=7, st_size=0, st_atime=1295990436, st_mtime=1295991135, st_ctime=1295990436)
3 2 posix.stat_result(st_mode=4096, st_ino=79119882, st_dev=84148224, st_nlink=0, st_uid=1140, st_gid=1, st_size=0, st_atime=1295991135, st_mtime=1295991135, st_ctime=1295991135)
5 8192 posix.stat_result(st_mode=53540, st_ino=56, st_dev=84410368, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=1269710532, st_mtime=1269710532, st_ctime=1269710532)
FAIL

Each line is in the following form: <fd> <value returned by F_GETFD> <os.fstat(fd)>

Here is my interpretation for fd 5 (which is the offending fd):
- a F_GETFD value of 8192 is different from both pipes (which return 2) and standard stdin/stderr (which return 8194); if the values haven't changed between Solaris versions, 8192 is O_LARGEFILE + O_RDONLY
- a st_mode of 53540 is stat.S_IFSOCK + stat.S_IFIFO + stat.S_IRUSR + stat.S_IRGRP + stat.S_IROTH; so this seems to be some kind of read-only (filesystem-based?) socket

I think it is unlikely that this socket is inherited from the parent process, or present before calling exec(). Instead, perhaps it's the startup of the child Python interpreter (after exec()) which creates such a file descriptor, and doesn't close it. Unfortunately, it seems difficult to diagnose this in more detail.
History
Date User Action Args
2011-01-25 21:55:44pitrousetrecipients: + pitrou, gregory.p.smith
2011-01-25 21:55:44pitrousetmessageid: <1295992544.44.0.542393820985.issue10826@psf.upfronthosting.co.za>
2011-01-25 21:55:43pitroulinkissue10826 messages
2011-01-25 21:55:43pitroucreate