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)
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>

No differences found
This page took 0.025433 seconds and 4 git commands to generate.