ntrack can get into endless poll loop if no backend modules found

[Alex Merry]

Note: this issue actually occurs for me in the context of kded4.

The attached sample program is a minimal test of the problem. Note that the problem only occurs if no backend modules can be found for ntrack.

If no backend modules can be found for ntrack, it uses the noop routines. This means that fd 0 is used for monitoring in QNtrack (because the calloc'd _ntrack_monitor_arch->data element is reinterpreted as an fd).

In the context of kded4, this happens to correspond to an open fd where the other side has been closed, so polling it always returns (I've simulated that in the test app with a pipe where I close the write end).

This means that polling fd 0 returns immediately with POLLHUP, ntrack's no-op routines are triggered (which do nothing), and control returns to the event loop where fd 0 is included in the poll() again, and the cycle continues.

Potential solution: create a dummy pipe (keeping both ends open) in the no-op routines, and return the read end of that.

[Alex Merry (randomguy3)]

This patch fixes the issue in the way I suggested (using a pipe).

[Alexander Sack (asac)]

question: why are no backend modules found?

otherwise, i posted a patch here on the infinite loop thing: https://bugs.launchpad.net/ntrack/+bug/755608/comments/19

[Alexander Sack (asac)]

anyway, this patch looks interesting and I might consider to take it for next release ...

I guess you don't have a problem with me relicensing this to BSD/MIT or LGPL-2 (i am considering licensing atm) if it comes to that?

[Alex Merry (randomguy3)]

Because of this: https://bugs.launchpad.net/ntrack/+bug/785153

The issue I describe here is actually completely different to that in bug 755608 - they just both happen to occur in the context of kded4. Certainly, revision 312 doesn't fix it, although it does apparently fix bug 755608. And I'm not getting an infinite loop within any method in libntrack; it's just that poll() never blocks in the main loop.

[Alex Merry (randomguy3)]

Nope, I hereby give you permission to use whatever license you wish for any patch I post on launchpad for ntrack.

[Alexander Sack (asac)]

took the patch slightly modified to ensure that the write end of the pipe is not used as a read fd by frontends.

------------------------------------------------------------
revno: 324
committer: Alexander Sack <email address hidden>
branch nick: ntrack
timestamp: Sun 2011-10-16 02:20:12 +0200
message:
  common: fix poll problems for noop monitor; use pipe to get valid rfds; thx to Alex Merry (randomguy3) lp:785119
------------------------------------------------------------

[Alexander Sack (asac)]

testing this I had to add a follow up patch to fix crashes in monitor recycle test. Point is that API hands our a copy of the rfds buffer and not the buffer itself.

------------------------------------------------------------
revno: 326
committer: Alexander Sack <email address hidden>
branch nick: ntrack
timestamp: Sun 2011-10-16 17:02:53 +0200
message:
  common: fix noop monitor crash caused by double free of pipe fd buffer; hand out copy of rfds
------------------------------------------------------------

[Alexander Sack (asac)]

ntrack 015 is available including the fix for this bug: https://launchpad.net/ntrack/main/015