LTTV trace control bug fix
authorChris Smowton <cs448@cam.ac.uk>
Wed, 18 Nov 2009 17:49:12 +0000 (12:49 -0500)
committerMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Wed, 18 Nov 2009 17:49:12 +0000 (12:49 -0500)
commit667dfdfea7441f2b7cf0d36f6ac7965b27dc768d
treeb92126f41b91cb4833ab92fd300b82b92a644bea
parent1d78e14a606d18d72a478019d84eead027e03f5e
LTTV trace control bug fix

Chris Smowton <cs448@cam.ac.uk>:

...whenever I tried
to start a trace using the GUI, it would freeze consuming 100% CPU after
I clicked "start". Turned out this was because in tracecontrol.c's
start_clicked callback, you poll(2) on an FD and use a switch()
statement to handle its return.

Unfortunately, poll(2) doesn't work that way -- it returns a *mask* of
bits, not a single value. Here poll was returning POLLIN | POLLHUP to
indicate there's data ready and the FD has been closed by the other
side, and since this != POLLIN and != POLLHUP, the poll loop spins
forever.

Attached is a patch to be applied to tracecontrol.c which fixes it to
check for set-bits instead. It's still strictly broken, as the read(fd,
buf, 256) call might not fully drain the child's output, but it's a step
in the right direction and means I can at least use the trace-control
thing.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
lttv/modules/gui/tracecontrol/tracecontrol.c
This page took 0.025019 seconds and 4 git commands to generate.