Re: Obscure bad file descriptor error on FreeBSD
"mal content" <artifact.one-gM/[email protected]> Thu, 7 Jun 2007 11:19:43 +0100
| Newsgroups | gmane.network.silc.devel |
|---|---|
| Message-ID | <[email protected]> |
On 07/06/07, Pekka Riikonen <[email protected]> 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 _______________________________________________________________________ Info: https://lists.silcnet.org/mailman/listinfo/silc-announce Archive: https://lists.silcnet.org/pipermail/silc-announce FAQ: http://silcnet.org/support/faq/