I got following result from tusc.

[changyoung]

I got following result from tusc.
Any guess about this error?

read(-1, 0x7aea0c08, 256) ............................................................................ [running]
read(-1, 0x7aea0c08, 256) ............................................................................ ERR#9 EBADF
read(-1, 0x7aea0c08, 256) ............................................................................ ERR#9 EBADF
read(-1, 0x7aea0c08, 256) ............................................................................ ERR#9 EBADF
read(-1, 0x7aea0c08, 256) ............................................................................ ERR#9 EBADF
read(-1, 0x7aea0c08, 256) ............................................................................ ERR#9 EBADF
etc.....

[A. Clay Stephenson]

Yes, the first argument to the read system call is a file descriptor. Valid values range from 0 to N. The file descriptor is obtained from an open(), pipe(), or socket() system call. All of these return -1 on a failed open(). It appears that the real problem is an open() is done but the result is ignored and passed on to the read() which sets errno = 9 (EBADF). You need to look for read()'s that return -1 in your tusc trace.

[A. Clay Stephenson]

Ooops my last sentence should be:
You need to look for open()'s that return -1 in your tusc trace.

[rick jones]

add accept() and perhaps the dup calls to that list :)

and if it isn't ignoring a return value from calls such as those mentioned, it could be someone reinitializing a variable somewhere where they shouldn't be.

in short, it is indicitive of an application bug