19 Oct
2014
19 Oct
'14
10:18 p.m.
High all,
now again an active post from me, obviously with a problem report.
Basic info: I'm running OpenSuse 13.1 with
TDE 3.5.13.2-3.oss131.opt.x86-64
Because somehow I couldn't get TDE's display manager to run, the one
in use is KDE4's, kdm-4.11.9-111.1.x86_64.
Today I was hinted to quassel for an IRC client, checked the Suse
repos, found and installed it. The installer reported as the only
unresolved dependency for quassel-mono (monolithic/stand-alone
package, nothing to do with the Mono runtime) the evenly provided
quassel-base package, which I confirmed to also install.
During the installation process, kicker crashed and when it was
attempted to be respawned, the CPU load increased to 50% overall
(2core HT current i5-M). The load was partially from kicker,
partially from kbuildsycoca. After killing both, I tried to
manually run kicker again, but the same happened, just with only
one thread worth of CPU load occupied.
"init 3" (I know it's not the same with systemd, but...) didn't even
kill kbuildsycoca. After manually killing it, I switched back to
RL 5, and I got the greeter screen (background), but no entry fields
or menus or whatever --- the CPU load was again at 25%.
After uninstalling the two quassel packages, I switched to RL 3 and
back to 5 again, but there was no difference. I rebooted the box,
and was prompted with the usual greeter, including the user/passwd
fields etc., entered the password and the same happened again:
25% CPU load, in kbuildsycoca. I attached gdb to it, without really
knowing what I should look for, but maybe one of you can read some
valuable information from the backtrace:
(gdb) bt
#0 0x00007f462f734980 in __read_nocancel () from /lib64/libc.so.6
#1 0x00007f462f6d0338 in __GI__IO_file_underflow () from /lib64/libc.so.6
#2 0x00007f462f6cf678 in __GI__IO_file_xsgetn () from /lib64/libc.so.6
#3 0x00007f462f6c5418 in fread () from /lib64/libc.so.6
#4 0x00007f46319525f7 in QFile::readBlock(char*, unsigned long) ()
from /usr/lib64/libqt-mt.so.3
#5 0x00007f463195c6df in QDataStream::operator>>(int&) ()
from /usr/lib64/libqt-mt.so.3
#6 0x00007f463265e1c8 in KSycoca::kfsstnd_prefixes() ()
from /opt/trinity/lib64/libkdecore.so.4
#7 0x00007f463265e3c8 in KSycoca::language() ()
from /opt/trinity/lib64/libkdecore.so.4
#8 0x00007f462d0aa20a in kdemain ()
from /opt/trinity/lib64/libkdeinit_kbuildsycoca.so
#9 0x00000000004090ff in ?? ()
#10 0x000000000040a008 in ?? ()
#11 0x000000000040a552 in ?? ()
#12 0x00000000004063be in main ()
gdb has also complained about plenty of missing debuginfo files for many
libraries involved with kbuildsycoca.
/proc/$(pidof kbuildsycoca)/maps lists
00400000-0040d000 r-xp 00000000 08:06 821948 /usr/local/opt/trinity/bin/kdeinit
which covers all three unknown functions in the backtrace. If you want
me to install it to exactly see which functions these are, just let me
know.
(Just btw: /opt is a symbolic link to /usr/local/opt.)
Thanks in advance,
Jagged
--
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error
19 Oct
19 Oct
10:53 p.m.
New subject: [trinity-users] kbuildsycoca hangs --- no login
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
High all,
now again an active post from me, obviously with a problem report.
Basic info: I'm running OpenSuse 13.1 with
TDE 3.5.13.2-3.oss131.opt.x86-64
Because somehow I couldn't get TDE's display manager to run, the one
in use is KDE4's, kdm-4.11.9-111.1.x86_64.
Today I was hinted to quassel for an IRC client, checked the Suse
repos, found and installed it. The installer reported as the only
unresolved dependency for quassel-mono (monolithic/stand-alone
package, nothing to do with the Mono runtime) the evenly provided
quassel-base package, which I confirmed to also install.
During the installation process, kicker crashed and when it was
attempted to be respawned, the CPU load increased to 50% overall
(2core HT current i5-M). The load was partially from kicker,
partially from kbuildsycoca. After killing both, I tried to
manually run kicker again, but the same happened, just with only
one thread worth of CPU load occupied.
"init 3" (I know it's not the same with systemd, but...) didn't even
kill kbuildsycoca. After manually killing it, I switched back to
RL 5, and I got the greeter screen (background), but no entry fields
or menus or whatever --- the CPU load was again at 25%.
After uninstalling the two quassel packages, I switched to RL 3 and
back to 5 again, but there was no difference. I rebooted the box,
and was prompted with the usual greeter, including the user/passwd
fields etc., entered the password and the same happened again:
25% CPU load, in kbuildsycoca. I attached gdb to it, without really
knowing what I should look for, but maybe one of you can read some
valuable information from the backtrace:
(gdb) bt
#0 0x00007f462f734980 in __read_nocancel () from /lib64/libc.so.6
#1 0x00007f462f6d0338 in __GI__IO_file_underflow () from /lib64/libc.so.6
#2 0x00007f462f6cf678 in __GI__IO_file_xsgetn () from /lib64/libc.so.6
#3 0x00007f462f6c5418 in fread () from /lib64/libc.so.6
#4 0x00007f46319525f7 in QFile::readBlock(char*, unsigned long) ()
from /usr/lib64/libqt-mt.so.3
#5 0x00007f463195c6df in QDataStream::operator>>(int&) ()
from /usr/lib64/libqt-mt.so.3
#6 0x00007f463265e1c8 in KSycoca::kfsstnd_prefixes() ()
from /opt/trinity/lib64/libkdecore.so.4
#7 0x00007f463265e3c8 in KSycoca::language() ()
from /opt/trinity/lib64/libkdecore.so.4
#8 0x00007f462d0aa20a in kdemain ()
from /opt/trinity/lib64/libkdeinit_kbuildsycoca.so
#9 0x00000000004090ff in ?? ()
#10 0x000000000040a008 in ?? ()
#11 0x000000000040a552 in ?? ()
#12 0x00000000004063be in main ()
gdb has also complained about plenty of missing debuginfo files for many
libraries involved with kbuildsycoca.
/proc/$(pidof kbuildsycoca)/maps lists
00400000-0040d000 r-xp 00000000 08:06 821948
/usr/local/opt/trinity/bin/kdeinit
which covers all three unknown functions in the backtrace. If you want
me to install it to exactly see which functions these are, just let me
know.
(Just btw: /opt is a symbolic link to /usr/local/opt.)
Thanks in advance,
Jagged
A cursory look at the bactrace indicates the process is stuck waiting for
I/O. Is the process stuck in D state (i.e. what does "ps aux" say about
it)?
Thanks!
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlREQNUACgkQLaxZSoRZrGFWDgDgsZDgl2yySA3GbF3nrw+gWtie
vcIubKMG1Cg4bgDeLcoeWGh3AjKyr0QNz2LGMk6nt0n1u5/xA/Vn7w==
=xZ/R
-----END PGP SIGNATURE-----
11:08 p.m.
New subject: [trinity-users] kbuildsycoca hangs --- no login
On Sun, Oct 19, 2014 at 05:53:10PM -0500, Timothy Pearson wrote:
A cursory look at the bactrace indicates the process
is stuck waiting for
I/O. Is the process stuck in D state (i.e. what does "ps aux" say about
it)?
Nope, "ps aux" says S+, but /proc/$(pidof kbuildsycoca)/stat says R;
However, when interrupting it from GDB, I always end up at the same
address, and a small disassembly shows that it is after a syscall
(read), so the interruption seems to interrupt this syscall.
(gdb) x/10i 0x7f462f734979
0x7f462f734979 <__read_nocancel>: mov $0x0,%eax
0x7f462f73497e <__read_nocancel+5>: syscall
=> 0x7f462f734980 <__read_nocancel+7>: cmp $0xfffffffffffff001,%rax
0x7f462f734986 <__read_nocancel+13>: jae 0x7f462f7349b9 <read+73>
0x7f462f734988 <__read_nocancel+15>: retq
0x7f462f734989 <read+25>: sub $0x8,%rsp
0x7f462f73498d <read+29>:
callq 0x7f462f74e370 <__libc_enable_asynccancel>
0x7f462f734992 <read+34>: mov %rax,(%rsp)
0x7f462f734996 <read+38>: mov $0x0,%eax
0x7f462f73499b <read+43>: syscall
read() receives it's file descriptor in RDI, which GDB prints as 10;
and /proc/$(pidof kbuildsycoca)/fd/10 points to
/var/tmp/kdecache-jagged/ksycoca,
which exists, and is empty; it's a regular file, owned by jagged:users,
with access (0644/-rw-r--r--) (no SElinux), which shouldn't be critical
anyway, since kbuildsycoca runs as root.
--
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error
20 Oct
20 Oct
8:15 p.m.
New subject: [trinity-users] kbuildsycoca hangs --- no login
On Mon, Oct 20, 2014 at 01:08:57AM +0200, Jagged O'Neill wrote:
/var/tmp/kdecache-jagged/ksycoca,
which exists, and is empty; it's a regular file, owned by jagged:users,
Okay, shy and humble as I am --- but is there no one who has an idea
about what goes wrong?
I mean, the name kbuildsycoca somehow implies that it writes the
file. It's fine that it also wants to read it, if necessary, but it
should figure when the file is empty and not just stop working...
regarding this behaviour I'm sure that it is a bug...
Anyway --- if not via kbuildsycoca --- how do I otherwise populate
the file?
Experts to the front please... thx
--
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error
9:17 p.m.
New subject: [trinity-users] kbuildsycoca hangs --- no login
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Mon, Oct 20, 2014 at 01:08:57AM +0200, Jagged
O'Neill wrote:
I haven't experienced this which is why I haven't commented. That being
said, you could try running kbuildsycoca --noincrememntal (as the user
experiencing the problem) to fully regenerate the database and see if that
helps.
Tim
/var/tmp/kdecache-jagged/ksycoca,
which exists, and is empty; it's a regular file, owned by jagged:users,
Okay, shy and humble as I am --- but is there no one who has an idea
about what goes wrong?
I mean, the name kbuildsycoca somehow implies that it writes the
file. It's fine that it also wants to read it, if necessary, but it
should figure when the file is empty and not just stop working...
regarding this behaviour I'm sure that it is a bug...
Anyway --- if not via kbuildsycoca --- how do I otherwise populate
the file?
Experts to the front please... thx -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlRFfAIACgkQLaxZSoRZrGG6qADgygaC8mdu8b+tFaStdSLmOFjG
SVAjnS8fpt2/sQDeONbpQqP6T1AqyNQ562YqtYeXC7DTZXmo1C8M+g==
=4+dz
-----END PGP SIGNATURE-----
9:48 p.m.
New subject: [trinity-users] kbuildsycoca hangs --- no login
On Mon, Oct 20, 2014 at 04:17:55PM -0500, Timothy Pearson wrote:
I haven't experienced this which is why I
haven't commented. That being
said, you could try running kbuildsycoca --noincrememntal (as the user
experiencing the problem) to fully regenerate the database and see if that
helps.
Maybe I should have been more inclined to experiment... this option
did indeed restore the cache.
But after a week of restoration of data from a crashed hard disk,
during which each inconsiderate experiment can lead to more data,
I was probably overly cautious...
Thanks a lot! (Adding this to my collection of useful recipes.)
--
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error
3486
days inactive
3487
days old
5 comments
2 participants
participants (2)
-
Jagged O'Neill -
Timothy Pearson