From owner-freebsd-ports@FreeBSD.ORG Mon Jun 9 01:28:38 2003 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A0C837B416; Mon, 9 Jun 2003 01:28:37 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [213.154.224.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A00E43FE3; Mon, 9 Jun 2003 01:28:36 -0700 (PDT) (envelope-from ted@open.nlnetlabs.nl) Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h598SYvr008966; Mon, 9 Jun 2003 10:28:34 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h598SYqI008965; Mon, 9 Jun 2003 10:28:34 +0200 (CEST) Message-Id: <200306090828.h598SYqI008965@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Mon, 9 Jun 2003 10:28:33 +0200 In-Reply-To: "Robert Watson's message as of Jun 9, 0:37" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Robert Watson , Arjan van Leeuwen cc: ports@freebsd.org cc: freebsd-current@freebsd.org cc: Ted Lindgreen cc: lioux@freebsd.org Subject: Re: Re Regression: Playing QT files from mplayer stopped working in 5.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 08:28:38 -0000 [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