Re: Re Regression: Playing QT files from mplayer stopped working in 5.1

[Quoting Robert Watson, on Jun  9,  0:37, in "Re: Re Regression: P ..."]

> So one interesting question would be: if you ktrace on both 4.x and 5.x,
> do both pass in the bad value to close(), or is there something else in
> 5.x triggering the use of negative file descriptor numbers?

I have no 4.x system with an old mplayer at hand at the moment, but
I can check it tomorrow if really necessary.

However, I guess that mplayer has had this error already, but that
a change in uthread_close.c as of May 31 has caused this problem
to show up now.
In particular: the unprotected usage of a very large value of "fd"
in "_thread_fd_table[fd]" leads to the segmentation violation.

Previously the systemcall just returned an error without getting
into a segmentation violation.

===================================================================
RCS file: uthread_close.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- uthread_close.c	2002/08/29 23:06:06	1.13
+++ uthread_close.c	2003/05/31 05:20:44	1.14
_at__at_ -49,9 +49,11 _at__at_
 	struct stat	sb;
 	struct fd_table_entry	*entry;
 
-	if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
+	if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
+	    (_thread_fd_table[fd] == NULL)) {
 		/*
-		 * Don't allow silly programs to close the kernel pipe.
+		 * Don't allow silly programs to close the kernel pipe
+		 * and non-active descriptors.
 		 */
 		errno = EBADF;
 		ret = -1;
===================================================================

So, there is a problem and a question:

Problem:
  mplayer calls close() with a bogus value.

Question:
  shouldn't _close in uthread_close.c do some sanity check on "fd"
  before using it as an array index?

Regards,
-- ted