Unfortunately the bug does seem to exist in KDE 4.6.4. It was said that one can test whether it really got stuck by disabling nepomuk. If virtuoso-t stops some time after that as well, everything is "ok" since it was just working on something and not just stuck. But now it seems that virtuoso-t is stuck in some loop, i.e. it uses one full core even 10 minutes after nepomuk was disabled and strace does not show any activity as well.
ps aux | grep virtuos
user 2454 1.6 4.1 250936 84940 ? SNl Jun29 135:54 /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_nn2440.ini +wait
strace -p 2454 -tt -s 1000
Process 2454 attached - interrupt to quit
15:04:42.952129 futex(0x108a424, FUTEX_WAIT_PRIVATE, 2439, NULL
and no change after minutes.
Attaching gdb to the process is somehow not possible, i.e. it reports:
Attaching to process 2454
/usr/bin/virtuoso-t (deleted): file or directory not found.
I can see the process in the list though and that file exists.
Unfortunately the bug does seem to exist in KDE 4.6.4. It was said that one can test whether it really got stuck by disabling nepomuk. If virtuoso-t stops some time after that as well, everything is "ok" since it was just working on something and not just stuck. But now it seems that virtuoso-t is stuck in some loop, i.e. it uses one full core even 10 minutes after nepomuk was disabled and strace does not show any activity as well.
ps aux | grep virtuos nn2440. ini +wait
user 2454 1.6 4.1 250936 84940 ? SNl Jun29 135:54 /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_
strace -p 2454 -tt -s 1000
Process 2454 attached - interrupt to quit
15:04:42.952129 futex(0x108a424, FUTEX_WAIT_PRIVATE, 2439, NULL
and no change after minutes.
Attaching gdb to the process is somehow not possible, i.e. it reports:
Attaching to process 2454
/usr/bin/virtuoso-t (deleted): file or directory not found.
I can see the process in the list though and that file exists.