27 Nov
2007
27 Nov
'07
7:49 p.m.
John Anderson wrote:
yes, people handed some strace outputs and it just boiled on some poll()
calls in libqt4, allegedly under QProcess class implementation. can't
say or dig any deeper from that, are just suspicions, not facts
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Tue, 2007-11-27 at 14:33 +0000, Rui Nuno Capela
wrote:
it's not quite a nominal qt4 version issue here, but seems to be due on
some circumstantial libqt4 build conditions (compile time flags?). for
example, i had this one report on debian testing (lenny) that the latest
libqt4-4.3.2 got it through alright, but most of the previous
iterations, including an early one also tagged as libqt4-4.3.2, was
indeed infected.
On Tue, November 27, 2007 12:10, John Anderson
wrote:
It also happens when I have an existing jackd running, and I start up
qjackctl.
I'm finding that qjackctl-0.3.0, 0.3.1 and
0.3.1a all use up 49% cpu. My
box is a CoreDuo, so that's probably 100% of one cpu.
qjackctl-0.2.22 doesn't do this, so I've downgraded for now.
If it's a bug, what can I do to help?
symptoms are that right after jackd is started the first time, qjackctl
starts eating 98% of a cpu, isn't it? it's a known issue on some Qt4 incarnations,
specially the debian based
ones, iirc. it has been reported on at least one case that updating to a
different libqt4 makes the issue go away.
I've just upgraded from qt-4.3.1 to qt-4.3.2, and the problem is still
there.
unfortunately,
i never caught that behavior reproduced on any of my
opensuse 10.x boxes, nor in windows :o)
Makes it kinda hard to debug ;-|