Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Mon, 9 Jun 2003 13:07:44 -0500 (CDT) [EMAIL PROTECTED] wrote: > I have mplayer in 4.8-STABLE and 5.1-RC1. What specifically would you like? The maintainer of mplayer is already looking into the problem. mplayer tries to close a file description which isn't open... it isn't even in the table of possible fds in libc, that's what causes the segfault with the revision 1.15 of uthread_close.c. If you are still interested you have to look at the source of mplayer. Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Mon, 9 Jun 2003 13:54:21 +0300 Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > This patch looks great. Please commit it. Done (rev 1.16). Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Mon, 9 Jun 2003 14:33:11 +0200 [EMAIL PROTECTED] (Ted Lindgreen) wrote: > I've tested it as cleanly as possible (make update, apply patch, > make world/kernel, and portupgrade -f multimedia/mplayer). > Is works fine and I haven't found any complications. > I think it's save to commit. Someone should still look into mplayer, I think there's something wrong with it. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
[Quoting Alexander Leidinger, on Jun 9, 11:23, in "Re: Re Regression: P ..."] > > shouldn't _close in uthread_close.c do some sanity check on "fd" > > before using it as an array index? > > Try the attached patch. > + if ((fd < 0) || (fd >= _thread_dtablesize) || This test looks perfectly right (should have been here already when the "_thread_fd_table[fd]" reference was added, I guess). I've tested it as cleanly as possible (make update, apply patch, make world/kernel, and portupgrade -f multimedia/mplayer). Is works fine and I haven't found any complications. I think it's save to commit. Thanks and regards, -- ted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Mon, Jun 09, 2003 at 11:22:45AM +0200, Alexander Leidinger wrote: > On Mon, 9 Jun 2003 10:28:33 +0200 > [EMAIL PROTECTED] (Ted Lindgreen) wrote: > > > 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. > > > Question: > > shouldn't _close in uthread_close.c do some sanity check on "fd" > > before using it as an array index? > > Try the attached patch. > Alexander, This patch looks great. Please commit it. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Mon, 9 Jun 2003 10:28:33 +0200
[EMAIL PROTECTED] (Ted Lindgreen) wrote:
> 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.
> Question:
> shouldn't _close in uthread_close.c do some sanity check on "fd"
> before using it as an array index?
Try the attached patch.
Bye,
Alexander.
--
Intel: where Quality is job number 0.9998782345!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Index: lib/libc_r/uthread/uthread_close.c
===
RCS file: /big/FreeBSD-CVS/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.15
diff -u -r1.15 uthread_close.c
--- lib/libc_r/uthread/uthread_close.c 31 May 2003 05:23:20 - 1.15
+++ lib/libc_r/uthread/uthread_close.c 9 Jun 2003 09:18:50 -
@@ -49,7 +49,8 @@
struct stat sb;
struct fd_table_entry *entry;
- if ((fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
+ if ((fd < 0) || (fd >= _thread_dtablesize) ||
+ (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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.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
@@ -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]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Sun, 8 Jun 2003, Arjan van Leeuwen wrote:
> Indeed, a very dirty but effective fix. Thank you. I'll forward this to
> ports@ and lioux@, who has done all the recent updates on mplayer.
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?
>
> Arjan
>
> On Sunday 08 June 2003 15:06, Ted Lindgreen wrote:
> > > Since a short time (don't know exactly when it happened) it's not
> > > possible anymore to play Quicktime files (.mov) with mplayer on
> > > 5.1-CURRENT. It has to be a change in -CURRENT, I haven't updated
> > > mplayer.
> >
> > I do not have the right fix, but the cause of the problem is
> > that in loader/win32.c at line 2077:
> >
> > 2076 if (v1 > 2)
> > 2077 if (!close(v1a))
> >
> > close is called with a ridiciously large value. In previous
> > FreeBSD releases this appearently did not cause a fatal problem,
> > but since a week or so mplayer aborts on it.
> >
> > A stupid, but effective workaround is not to call close if v1
> > is too large, f.i.:
> >
> > 2072 static int WINAPI expCloseHandle(long v1)
> > 2073 {
> > 2074 dbgprintf("CloseHandle(0x%x) => 1\n", v1);
> > 2075 /* do not close stdin,stdout and stderr */
> > 2076 if (v1 > 2 && v1 < 128)
> > 2077 if (!close(v1))
> > 2078 return 0;
> > 2079 return 1;
> > 2080 }
> >
> > Of course for the real fix one needs to delve deeper into mplayer
> > to find out where the large valued filedescriptor comes from.
> >
> > -- ted
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
Indeed, a very dirty but effective fix. Thank you. I'll forward this to ports@
and lioux@, who has done all the recent updates on mplayer.
Arjan
On Sunday 08 June 2003 15:06, Ted Lindgreen wrote:
> > Since a short time (don't know exactly when it happened) it's not
> > possible anymore to play Quicktime files (.mov) with mplayer on
> > 5.1-CURRENT. It has to be a change in -CURRENT, I haven't updated
> > mplayer.
>
> I do not have the right fix, but the cause of the problem is
> that in loader/win32.c at line 2077:
>
> 2076 if (v1 > 2)
> 2077 if (!close(v1a))
>
> close is called with a ridiciously large value. In previous
> FreeBSD releases this appearently did not cause a fatal problem,
> but since a week or so mplayer aborts on it.
>
> A stupid, but effective workaround is not to call close if v1
> is too large, f.i.:
>
> 2072 static int WINAPI expCloseHandle(long v1)
> 2073 {
> 2074 dbgprintf("CloseHandle(0x%x) => 1\n", v1);
> 2075 /* do not close stdin,stdout and stderr */
> 2076 if (v1 > 2 && v1 < 128)
> 2077 if (!close(v1))
> 2078 return 0;
> 2079 return 1;
> 2080 }
>
> Of course for the real fix one needs to delve deeper into mplayer
> to find out where the large valued filedescriptor comes from.
>
> -- ted
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
