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
-----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
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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
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
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.)
-
Jagged O'Neill -
Timothy Pearson