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.
This patch fixes the issue in the way I suggested (using a pipe).