trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: October 2014

Re: [trinity-users] kbuildsycoca hangs --- no login

From: "Timothy Pearson" <kb9vqf@...>
Date: Sun, 19 Oct 2014 17:53:10 -0500
-----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-----