|
From: Steve G <lin...@ya...> - 2003-12-26 13:37:34
|
Hi, I stepped up to the latest 2.1.0 release and was happy to see new bugs being reported for the first time. I was testing against the cvs copy of xinetd and I see this: Warning: invalid file descriptor -1 in syscall close() OK, we set some descriptors to -1 when they have been previously closed and I'd like to find this bug...but there's no location information given in the output. No stack trace. Is there a way to enable this? I'm 100% sure this is an xinetd bug, I'd like to fix it. Another thing that xinetd does on startup is close all file descriptors between 2 & FD_SETSIZE or lim_max as returned by getrlimit() (or getdtablesize if RLIMIT_NOFILE is not available), whichever is lower. The curious things is that valgrind started reporting close syscall errors from 821-1023. Where is valgrind getting the 821 from? Xinetd does try to set the fd limit by using setrlimit. Valgrind should be able to track this value since it intercepts syscalls. The reason I'm curious is that it seems xinetd or valgrind is miscalculating the maximum fd number. Thanks, Steve Grubb __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ |
|
From: Dirk M. <dm...@gm...> - 2003-12-26 20:22:34
|
On Friday 26 December 2003 14:37, Steve G wrote: > whichever is lower. The curious things is that valgrind started > reporting close syscall errors from 821-1023. known valgrind bug of 2.1.0, fixed in HEAD (will be in 2.1.1). ignore it. about the other problem.. we've to implement backtrace-resolving upon such events. Dirk |
|
From: Jeremy F. <je...@go...> - 2003-12-26 20:28:48
|
On Fri, 2003-12-26 at 05:37, Steve G wrote: > OK, we set some descriptors to -1 when they have been previously > closed and I'd like to find this bug...but there's no location > information given in the output. No stack trace. Is there a way > to enable this? -v. --track-fds=yes should probably enable this too. > Another thing that xinetd does on startup is close all file > descriptors between 2 & FD_SETSIZE or lim_max as returned by > getrlimit() (or getdtablesize if RLIMIT_NOFILE is not available), > whichever is lower. The curious things is that valgrind started > reporting close syscall errors from 821-1023. Where is valgrind > getting the 821 from? Valgrind needs to use file descriptors for its own internal use, so it prevents the client from using a range of descriptors. HEAD now updates the soft limit to reflect this (though I don't think it enforces a hard limit). J |
|
From: Robert W. <rj...@du...> - 2003-12-26 20:33:09
|
> -v. --track-fds=yes should probably enable this too. Actually, -v is all that's needed here. --track-fds might pop up other problems, though. |
|
From: Steve G <lin...@ya...> - 2003-12-26 21:50:40
|
>> -v. --track-fds=yes should probably enable this too. > Actually, -v is all that's needed here. --track-fds might >pop up other problems, though. Right, "-v" does the trick. I had already tried track-fds with no luck. I'd like to suggest that the stack trace be given by default. As it stands, if you get one of these, you'll have to re-run valgrind just to find it. Now to go fix my bug... Thanks, -Steve Grubb __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |
|
From: Jeremy F. <je...@go...> - 2003-12-26 23:55:17
|
On Fri, 2003-12-26 at 12:33, Robert Walsh wrote: > > -v. --track-fds=yes should probably enable this too. > > Actually, -v is all that's needed here. --track-fds might pop up other > problems, though. No, I meant that --trace-fds (rather than -v) should probably turn on stack traces for all this stuff, since you're clearly interested in fds. J |
|
From: Robert W. <rj...@du...> - 2003-12-27 00:12:17
|
> No, I meant that --trace-fds (rather than -v) should probably turn on > stack traces for all this stuff, since you're clearly interested in fds. I see. Actually, Steve's follow-up point was probably more valid, though: always print a backtrace when you print this error. |
|
From: Jeremy F. <je...@go...> - 2003-12-27 08:08:48
|
On Fri, 2003-12-26 at 16:12, Robert Walsh wrote: > > No, I meant that --trace-fds (rather than -v) should probably turn on > > stack traces for all this stuff, since you're clearly interested in fds. > > I see. Actually, Steve's follow-up point was probably more valid, > though: always print a backtrace when you print this error. It can get pretty noisy. There's quite a few programs which do lots of indiscriminate closing of fds. J |
|
From: Steve G <lin...@ya...> - 2003-12-27 13:39:32
|
>It can get pretty noisy. There's quite a few programs which >do lots of indiscriminate closing of fds. I'd say give 'em the output. If its noisy, it should be a clue that something needs fixing. They should be able to generate a suppression for it if its too painful. The issue that I'm really thinking should be a avoided is when you are working on something that has a race condition and its hard to trigger the error. The way it currently is, you would have to try to reproduce the race just to find out where the problem was coming from. I think its more consistent if warnings were printed by default and suppressions reduce the noise. Memory problems are printed by default, so why not syscall problems? (I think version 1.9.6 printed stack traces for syscall problems.) -Steve Grubb __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ |