On Sun, 8 Jun 2003, Arjan van Leeuwen wrote: > Indeed, a very dirty but effective fix. Thank you. I'll forward this to > ports_at_ and lioux_at_, 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 > > _______________________________________________ > > freebsd-current_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Sun Jun 08 2003 - 13:37:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:11 UTC