Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Bug report: fcloseall() and stdin, stdout, and stderr/List of Posts
Forum Topic - Bug report: fcloseall() and stdin, stdout, and stderr: (6 Items)
   
Update
Will Miles
03/10/2009 12:33 PM
post24039
Bug report: fcloseall() and stdin, stdout, and stderr   
Hi,

I'm still poking at the cron sources, tracking down why the log messages wind up in slogger instead of syslog after the 
fork() in trigger().  It turns out this is because the close(STDIN_FILENO) actually ends up closing the syslog fd.  This
 in turn seems to be because the fcloseall() call in main() is closing stdin, stdout, and stderr, even though the 
documentation explicitly states that it does not - thus when openlog() runs it gets fd 0.  The function source in lib\c\
stdio\fcloseall.c seems to confirm this behaviour: the loop starts at _Files[0] (eg. stdin) instead of _Files[3].

Is this a bug in the library or the documentation?

-Will
Shiv Nagarajan(deleted)
03/10/2009 12:38 PM
post24040
Re: Bug report: fcloseall() and stdin, stdout, and stderr   
I think thats a bug. the docs do say fcloseall will not close
stdin, stdout, stderr. 

let me poke around and determine where the bug is and create an
appropriate PR for this

shiv
Tue Mar 10 12:38:17 EDT 2009
 --> According to Will Miles <--
	Hi,
	
	I'm still poking at the cron sources, tracking down why the log messages
	wind up in slogger instead of syslog after the fork() in trigger().  It
	turns out this is because the close(STDIN_FILENO) actually ends up
	closing the syslog fd.  This in turn seems to be because the fcloseall()
	call in main() is closing stdin, stdout, and stderr, even though the
	documentation explicitly states that it does not - thus when openlog()
	runs it gets fd 0.  The function source in lib\c\stdio\fcloseall.c seems
	to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
	instead of _Files[3].
	
	Is this a bug in the library or the documentation?
	
	-Will
	
	_______________________________________________
	OSTech
	http://community.qnx.com/sf/go/post24039
	

-- 
****
Shiv Nagarajan,
Kernel Developer, QNX Software Systems,
Ottawa, Canada
****
Colin Burgess(deleted)
03/10/2009 12:52 PM
post24043
Re: Bug report: fcloseall() and stdin, stdout, and stderr   
It's interesting... fcloseall is listed as being of the "QNX4" classification.  And the watcom docs state
the same caveat.

fcloseall() in newlib (from cygwin) on the other hand DOES close all streams
_fcloseall() in MS C doesn't close the standard streams
fcloseall() in linux closes all streams

so there doesn't appear to be a good standard out there.

It should probably match the original watcom libc behaviour, which appears to be that documented.

Shiv Nagarajan wrote:
> I think thats a bug. the docs do say fcloseall will not close
> stdin, stdout, stderr. 
> 
> let me poke around and determine where the bug is and create an
> appropriate PR for this
> 
> shiv
> Tue Mar 10 12:38:17 EDT 2009
>  --> According to Will Miles <--
> 	Hi,
> 	
> 	I'm still poking at the cron sources, tracking down why the log messages
> 	wind up in slogger instead of syslog after the fork() in trigger().  It
> 	turns out this is because the close(STDIN_FILENO) actually ends up
> 	closing the syslog fd.  This in turn seems to be because the fcloseall()
> 	call in main() is closing stdin, stdout, and stderr, even though the
> 	documentation explicitly states that it does not - thus when openlog()
> 	runs it gets fd 0.  The function source in lib\c\stdio\fcloseall.c seems
> 	to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> 	instead of _Files[3].
> 	
> 	Is this a bug in the library or the documentation?
> 	
> 	-Will
> 	
> 	_______________________________________________
> 	OSTech
> 	http://community.qnx.com/sf/go/post24039
> 	
> 

-- 
cburgess@qnx.com
Colin Burgess(deleted)
03/10/2009 1:41 PM
post24050
Re: Bug report: fcloseall() and stdin, stdout, and stderr   
On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
leave it as it is, fixing the docs.

Of course we should then fix cron... :-)

Shiv Nagarajan wrote:
> I think thats a bug. the docs do say fcloseall will not close
> stdin, stdout, stderr. 
> 
> let me poke around and determine where the bug is and create an
> appropriate PR for this
> 
> shiv
> Tue Mar 10 12:38:17 EDT 2009
>  --> According to Will Miles <--
> 	Hi,
> 	
> 	I'm still poking at the cron sources, tracking down why the log messages
> 	wind up in slogger instead of syslog after the fork() in trigger().  It
> 	turns out this is because the close(STDIN_FILENO) actually ends up
> 	closing the syslog fd.  This in turn seems to be because the fcloseall()
> 	call in main() is closing stdin, stdout, and stderr, even though the
> 	documentation explicitly states that it does not - thus when openlog()
> 	runs it gets fd 0.  The function source in lib\c\stdio\fcloseall.c seems
> 	to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> 	instead of _Files[3].
> 	
> 	Is this a bug in the library or the documentation?
> 	
> 	-Will
> 	
> 	_______________________________________________
> 	OSTech
> 	http://community.qnx.com/sf/go/post24039
> 	
> 

-- 
cburgess@qnx.com
Neil Schellenberger(deleted)
03/10/2009 2:24 PM
post24058
Re: Bug report: fcloseall() and stdin, stdout, and stderr   
FWIW, apropos the discussion in our meeting today, it seems the most
flexible to me to stick with the "closes everything except stdin,
stdout, stderr".  That would help applications t oavoid the possibility
of loosing the standard fds.  The user could still explicitly fclose()
the standard streams if they really, really meant it ;-)

On Tue, 2009-03-10 at 13:41 -0400, Colin Burgess wrote:
> On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
> leave it as it is, fixing the docs.
> 
> Of course we should then fix cron... :-)
> 
> Shiv Nagarajan wrote:
> > I think thats a bug. the docs do say fcloseall will not close
> > stdin, stdout, stderr. 
> > 
> > let me poke around and determine where the bug is and create an
> > appropriate PR for this
> > 
> > shiv
> > Tue Mar 10 12:38:17 EDT 2009
> >  --> According to Will Miles <--
> > 	Hi,
> > 	
> > 	I'm still poking at the cron sources, tracking down why the log messages
> > 	wind up in slogger instead of syslog after the fork() in trigger().  It
> > 	turns out this is because the close(STDIN_FILENO) actually ends up
> > 	closing the syslog fd.  This in turn seems to be because the fcloseall()
> > 	call in main() is closing stdin, stdout, and stderr, even though the
> > 	documentation explicitly states that it does not - thus when openlog()
> > 	runs it gets fd 0.  The function source in lib\c\stdio\fcloseall.c seems
> > 	to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> > 	instead of _Files[3].
> > 	
> > 	Is this a bug in the library or the documentation?
> > 	
> > 	-Will
> > 	
> > 	_______________________________________________
> > 	OSTech
> > 	http://community.qnx.com/sf/go/post24039
> > 	
> > 
>
Will Miles
03/10/2009 3:21 PM
post24067
Re: Bug report: fcloseall() and stdin, stdout, and stderr   
Sounds good to me.  Thanks for looking in to it!   I hope nothing else
gets bitten by the change in behaviour.

As a short term workaround in my local build I've replaced the fcloseall
() with procmgr_daemon() [also eliminating the need to explicitly
background the program when called].    It turns out that even in this
case cron still needs a fix, though a different one: the fd used to
cache stderr while spawning the target job is currently #defined to 4,
which also happens to be the fd handed to openlog().  STDERR2 needs to
be changed to some other number for the output-catching logic to work
correctly.   I just used 5, though perhaps a larger value is less
likely to collide with something in the future.

Thanks again,

-Will


On Tue, 10 Mar 2009 14:24:56 -0400 (EDT)
Neil Schellenberger <community-noreply@qnx.com> wrote:

> FWIW, apropos the discussion in our meeting today, it seems the most
> flexible to me to stick with the "closes everything except stdin,
> stdout, stderr".  That would help applications t oavoid the possibility
> of loosing the standard fds.  The user could still explicitly fclose()
> the standard streams if they really, really meant it ;-)
> 
> On Tue, 2009-03-10 at 13:41 -0400, Colin Burgess wrote:
> > On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
> > leave it as it is, fixing the docs.
> > 
> > Of course we should then fix cron... :-)
> > 
> > Shiv Nagarajan wrote:
> > > I think thats a bug. the docs do say fcloseall will not close
> > > stdin, stdout, stderr. 
> > > 
> > > let me poke around and determine where the bug is and create an
> > > appropriate PR for this
> > > 
> > > shiv
> > > Tue Mar 10 12:38:17 EDT 2009
> > >  --> According to Will Miles <--
> > > 	Hi,
> > > 	
> > > 	I'm still poking at the cron sources, tracking down why the log messages
> > > 	wind up in slogger instead of syslog after the fork() in trigger().  It
> > > 	turns out this is because the close(STDIN_FILENO) actually ends up
> > > 	closing the syslog fd.  This in turn seems to be because the fcloseall()
> > > 	call in main() is closing stdin, stdout, and stderr, even though the
> > > 	documentation explicitly states that it does not - thus when openlog()
> > > 	runs it gets fd 0.  The function source in lib\c\stdio\fcloseall.c seems
> > > 	to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> > > 	instead of _Files[3].
> > > 	
> > > 	Is this a bug in the library or the documentation?
> > > 	
> > > 	-Will
> > > 	
> > > 	_______________________________________________
> > > 	OSTech
> > > 	http://community.qnx.com/sf/go/post24039
> > > 	
> > > 
> > 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post24058
> 
> 


-- 
Will Miles <wmiles@sgl.com>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems