[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
@@ -49,9 +49,11 @@
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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
