Obscure bad file descriptor error on FreeBSD

[mal content]

On 07/06/07, Pekka Riikonen <priikone at iki.fi> wrote:
>
> : 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).

Yes.

>
> 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?
>

No, they're never used outside of the confdir_* functions.

>
> 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.
>

Ok.

More to follow...
MC