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