Obscure bad file descriptor error on FreeBSD

[Pekka Riikonen]

: Note that my process called open() and got file descriptor 0 returned
: to it. A bit further on:
: 
:  37529 s706     RET   read 1
:  37529 s706     CALL  write(0x7,0x8065800,0x30)
:  37529 s706     GIO   fd 7 wrote 48 bytes
:        0x0000 0026 0002 0a00 1008 0200 0000 0000 0000  |.&..............|
:        0x0010 0000 0000 0000 0000 0001 c0a8 0321 d229  |.............!.)|
:        0x0020 c4eb 2e70 c30e e2a6 4f1f da46 0000 0000  |...p....O..F....|
:  37529 s706     RET   write 48/0x30
:  37529 s706     CALL  fcntl(0,0x3,0)
:                       ^^^^^^^^^^^^^^
:                       This is where I added an assertion in
:                       silcunixschedule.c
: 
: descriptor 0 to be the socket connected to the server when in fact
: isn't. This could have happened because when the process called fork(),
: my client modified the file descriptor table by closing a file and
: obviously the silc client library couldn't be aware of this.
: 
: Unfortunately, I've still not been able to track down why the file
: descriptor becomes invalid. I can connect to the server, run commands,
: do all of the usual essentials but when the client is doing nothing,
: it's endlessly looping on a failed poll() call...
: 
First, it's odd that you get fd 0 in the first place.  Isn't 0 reserved 
for stdin, at least according to stdin(3).

Second, do you pass these file descriptors you open with these confdir_* 
functions to SILC Scheduler?  And if you do, how do you pass them?

Third, if SILC scheduler does listen to these fd's and you close them or 
FreeBSD closes them, the Fd task must be removed from the scheduler.  If 
it isn't it will re-schedule it can the end result is bad file descriptor 
error.

Fourth, the byte "!" that the SILC scheduler read is the 
silc_schedule_wakeup call that sends "!" byte to the wakeup socket.  The 
socket is opened by the scheduler when silc_schedule_init is called.  It 
must not be closed.  If it is, the behavior of the scheduler is 
undefined.  You don't have access to that fd directly so only way to close 
that is by doing it intentionally, ie. specifically closing that fd.

Without seeing code and debug outputs I can't say what's wrong.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/