Obscure bad file descriptor error on FreeBSD

mal content artifact.one at googlemail.com
Thu Jun 7 12:19:43 CEST 2007


On 07/06/07, Pekka Riikonen <priikone at iki.fi> wrote:
>
> Isn't the following the cause of the problem:
>
> :  37529 s706     RET   open 9
> fd = open();
> fd == 9
> :  37529 s706     CALL  fchdir(0x3)
> :  37529 s706     RET   fchdir 0
> ret = fchdir(3);
> ret == 0;
> :  37529 s706     CALL  open(0x804e5c6,0x104,0)
> :  37529 s706     NAMI  "server_key"
> :  37529 s706     RET   open -1 errno 2 No such file or directory
> fd = open("server_key")
> fd == -1
> :  37529 s706     CALL  fchdir(0x9)
> :  37529 s706     RET   fchdir 0
> ret = fchdir(9);
> ret == 0;
> :  37529 s706     CALL  close(0)
> :  37529 s706     RET   close 0
> ret == close(0);
> ^^^^^^^^^^^^^^
> ret == 0
>
> shouldn't this read close(9) or close(3).  I can't see you opening fd 0
> anywhere but I see you closing it.

Oh dear, oh dear, oh dear.

I've been doing this since 5AM, and after replacing every
single open() and close() call with a central function
in a vain attempt to track file descriptors (valgrind
would just helpfully crash as pthread_attr* is not
currently implemented and the SILC library uses it
somewhere), I discover this gem:

  if (confdir_close_fd(cd->prevfd == -1)) {
     ...

Look at that one closely. Seems a ')' decided to go on
a short walk. That's one of the ugliest bugs I've ever
witnessed.

Thanks for not judging too harshly. I'm off to the home
for damaged C programmers.

In conclusion, not SILC's fault.
MC


More information about the silc-devel mailing list