-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/03/2015 07:53 AM, dep wrote:
> said Gerhard Zintel: | On Friday 02 January 2015, dep wrote: | > said Michele Calgaro: | > | On 12/28/2014 08:15
> AM, dep wrote: | > | > sorry to be such a bother, but as long as i'm bringing things up, | > | > here's one that
> has been an issue for a couple of years and | > | > survived into R14. | > | > | > | > my desktop crashes, but in
> such a way as to not even be noticeable | > | > at first. | > | > | > | > i have in lieu of wallpaper xplanet set
> up as a realtime moon | > | > phase indicator, updating hourly. the way i tell the desktop has | > | > crashed is
> that it doesn't update -- in this case it last | > | > refreshed at 10:30 a.m. yesterday. i believe that i was
> probably | > | > editing pictures at that time, though would not swear to it. | > | > | > | > after it crashes, a
> right click on the desktop does not produce | > | > the expected menu. as it happens, kicker and everything else |
> > | > continues to function as expected -- in fact, it was just now that | > | > i noticed that the desktop itself
> had gone south. | > | > | > | > i thought i'd look in the x error log, bit i see that the one i | > | > have,
> ~/.xsession-errors, is of an unspecified file type and won't | > | > open in a text editor (it reports its size as
> 500.0 k). | > | > | > | > any idea if there's a log that might let me see what's going on | > | > here and if so
> what log it might be? bonus points, how i might | > | > restart the desktop without logging out and back in? extra
> bonus | > | > points, how i might fix it so it doesn't do this anymore? i'm | > | > running some flavor of ubuntu
> 12.04LTS -- i say some flavor | > | > because when i sought to upgrade a few days ago the ubuntu | > | > upgrader
> refused, citing third-party apps or a beta version of the | > | > opsys, or something; it didn't specify. i thought
> i had bog | > | > standard 12.04LTS on the machine but am apparently wrong. | > | | > | sorry for the late reply.
> The desktop behavior is controlled by the | > | kdesktop process. When your desktop stops updating, from CLI type: 
> | > | ps aux | grep desktop | > | and see if there is something like: | > | username      8414  0.4  0.7 260192
> 28956 pts/8    Sl   12:50   0:00 | > | kdesktop | > | > avahi     1973  0.0  0.0  32308  1732 ?        S     2014
> 0:01 | > avahi-daemon: running [dep-desktop.local] | > dep       3200  0.0  0.1 252184 17972 ?        Sl    2014 |
> > 1:04 /opt/trinity/bin/kdesktop | > dep      11289  0.0  0.0      0     0 ?        Z     2014   0:02 | >
> [kdesktop_lock] <defunct> | > dep      29758  0.0  0.0   9388   904 pts/0    S+   16:12   0:00 grep | > desktop |
> > | > nevertheless, it hasn't updated since 10:19:53 AM 26 December. and a | > rmb click on the desktop does not
> produce the expected menu. | > | > | If not, kdesktop has crashed. You can type: | > | kdesktop & from CLI to
> restart it (or alternatively Alt-F2 and then | > | kdesktop). | > | > dep@dep-desktop:~$ kdesktop is already
> running! | > | > | If this brings everything back in order, please let us know because | > | we need some more
> advanced testing to understand why and where | > | kdesktop crashed. | > | > fwiw, top reports 3 zombies. | | have
> you tried to kill the running kdesktop beforehand (not the | defuncts)? I assume it runns under process number
> 3200. Thus: | $ kill -9 3200 | | and than launch kdesktop again?
> 
> this worked. i do not know if we learned anything from its having worked, but work it did.
> 
> thanks!
> 

kdesktop_lock died and has not been reaped, so I suspect that kdesktop may be waiting on some unreleased mutex, which
would be the reason why the background does not update any more and the RMB click doesn't do anything.
Something obviously went wrong.
The next time you see the error, can you try the following:
1) ps aux | grep kdesktop   -> this should give again kdesktop_lock <defunct>
2) take note of the kdesktop pid (not the kdesktop_lock)
3) from CLI (not within TDE, but from a tty), run: gdb --pid=<pid of kdesktop>  --> you may try from a TDE console,
but you may loose the keyboard. In such case you have to switch to a tty, kill the gdb instance and retry from there.
4) type: thread apply all bt
Report what is printed out. This hopefully will provide some additional info.
If it is not critical for you, please do not exit gdb and do not kill and restart kdesktop. Depending on what we find,
we may have to run some other commands.

By the way, can you open a proper bug report on our bugszilla? It looks like there is something to fix here :-)

Cheers
  Michele



































-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJUp4wYAAoJECp1t8qK3tXPyv4QAJN2BCsDKCe4iMeMeFL78o6H
FRCIARwVlnSltXJGNiBiNOyqC4jmpcRd4FvTar/HENS6L6QPOmaeOj0/zb+8jSIn
Nv1cGu8jVHxZ/+/iu7z+dS8oEJnD3xe14OfB6DrtvkMNoHU81vin9ZCcaCa0Gt83
u0kgk36PJfmKr0cjEGDX2urrxdCNT5NWrhP0dpr2serkbqOAxCMr0lCOoGYqPpds
zLGE9gNh3ZNxN1CUQZytZvuuMCN2S4yYEasEzAWzBV6drC272XkKj1aMJs9xIXh1
YHe1gyY405OP8mvtXU9tvhpbbislaa3T8GnFHsrdxgCmL4OLLGntshJhYDEzLCyO
CMqZ0WObMkPSrDeo42Zxy2Rb8n6TjFz2vuW1U7OQidlMVgrGNJZ1m6SItT7k+Yd+
EtYLuuXhQIRBXZOsQpIgsJVMDw4+Eqx7ceLO4Rfd6P53vIcRgLlgpoqf/wThluOI
ekZvUJQWxF266m8+PVSq/+INbPl+lqD1/e5V2hPxq44u8OF4jCFMtLTX+m4g/Dyx
eXdJ4TwuwoPlapxlz6ZQDFGDi0tAKQ/fCDaNLIsxLl7iEba01wl/XF16LOwLG0tn
pJiESJ2BwRCtYD1iANFZL7vtQEAPhVkzey4FtPpMIyD/1CVTwXeHk3wepNSa9JAx
Fsk1AiIvHeejLEA6b2Gn
=2axv
-----END PGP SIGNATURE-----