[MPlayer-dev-eng] Stuck mouse buttons, a Linux kernel bug?

[Ivan Kalvachev]

Hi,
I have spend some time looking at the problem.
It was a good. not_so_short unix programing course.

So what is the problem. 
Create e pipe, and write one (in this case 4) byte in it.
If you use select() to see if the another write will block
(in other words the pipe is full), you will get report that
it will. Actually the pipe is not really full and you can write another symbol.
The real block will occure when the pipe is really full that should be about 4096 bytes.


What have this to do with MPlayer? If there are 2 events that are passed in very
short time, one of them will be dropped because select() will report that the pipe
is full.
I tried to fix the code that use select(), but it obviously was wrong approach.

So I don't see any other solution that to accept the proposed patch. I have
tweaked it a little and I attached the version I am going to commit tommorow.

If I am not mistaken the credits should go to Marius Gedminas. Please confim that,
as there are some problem checking this by myself. 


I would like to know if O_NONBLOCK have some portability issues, so they
could be workarounded by configure.


So after we workarounded the bug, the select() itself should be fixed.
I'm not sure should and where to report the bug, so I would accept 
any advice. So far I have marked Linux Kernel maillist as best candidate.
But from my personal experience it should be security or stability risk
in order to be noticed.
Anyway I have made an small simple sample lame program to illustrate it. 
(also attached)

anyway, make into account that select() documentation states:

"The way that select is usually used is to block while waiting for  a  "change  of
 status"  on one or more of the file descriptors. A "change of status" is when ....
 ... space  becomes available within the kernel's internal buffers for more
 to be written to the file descriptor..."

I hope this is bug, not feature ;)

Wish You Best
   Ivan Kalvachev
  iive



On Tue, 26 Oct 2004 20:13:10 -0300
"Reynaldo H. Verdejo Pinochet" <reynaldo at opendot.cl> wrote:

> On Sat, Oct 23, 2004 at 01:59:56PM +0200, Diego Biurrun wrote:
> Content-Description: message body text
> > D Richard Felker III writes:
> > > On Fri, Oct 22, 2004 at 02:12:04AM +0200, Diego Biurrun wrote:
> > > > The Wanderer writes:
> > > > > Diego Biurrun wrote:
> > > > > 
> > > > > > Marius Gedminas writes:
> > > > > > 
> > > > > >> Occasionally (but often enough to get annoying) when I click a
> > > > > >> mouse button on an mplayer window the button gets stuck
> > > > > 
> > > > > >> I've traced the problem to mplayer_put_key in fifo.c.
> > > > > 
> > > > > > I just tested this patch and it works as advertised.  We should
> > > > > > really fix this ancient bug.  Somebody please review and commit this.
> > > > > 
> > > > > I'm not sure what "reviewing" consists of in this type of context, aside
> > > > > from looking the code over and saying "it looks okay to me" (in which
> > > > > case I wouldn't be remotely qualified to pass on it), but at the very
> > > > > least the printfs it adds to fifo.c will need to be changed to mp_msg.
> > > > 
> > > > Yes, you're right.  In this case the printfs look like mere debugging
> > > > aids, though, so I would guess commenting them out (like the others in
> > > > that file) should suffice.
> > > 
> > > yes, printf should not be in mplayer output by default. it needs to be
> > > commented, conditional, or mp_msg...
> > 
> > Here's a version with the printfs commented out..
> > 
> > Diego
> I have comed out to find some commented out printf's that could really
> be MSGL_DBG4 or so, what would it be of best practice? just
> commenting them out or building a correct mp_msg sentence with
> a _debug_ message level? im not talking just about this patch
> (to be fair i havent even had a look at it ;-) but other small
> files or no so important ones like, ie sub_find.c (last one
> i looked).
> 
> any suggestion will be greatly apreciated.
> 
> Regards
> 
>     Reynaldo
> 	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stuck_fix2.patch
Type: application/octet-stream
Size: 1488 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041104/4355b441/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipe_select.c
Type: application/octet-stream
Size: 1091 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041104/4355b441/attachment-0001.obj>