Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the login screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use screensaver or lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace if that would help and if someone could give directions on howto. I will file a bug with the backtrace.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the login screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use screensaver or lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace if that would help and if someone could give directions on howto. I will file a bug with the backtrace.
Well that's strange. When you mention it crashing your Xorg session does that mean the Xorg server itself crashes (i.e. instantaneous dump back to the command line) or that TDE terminates leaving Xorg still running?
kdesktop_lock is spawned from kdesktop, so any debugging would likely involve terminating kdesktop and running kdesktop_lock under gdb from a terminal. When I have an answer to the above question I'll get back to you on how to debug further.
Also, Did this bug first appear in RC2 or did it show up earlier?
Thanks!
Tim
On Tuesday 02 December 2014 17:57:06 you wrote:
Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the login screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use screensaver or lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace if that would help and if someone could give directions on howto. I will file a bug with the backtrace.
Well that's strange. When you mention it crashing your Xorg session does that mean the Xorg server itself crashes (i.e. instantaneous dump back to the command line) or that TDE terminates leaving Xorg still running?
I do not think the x server crashed,I get dropped to the login prompt pretty quickly, does not seem like enough time to restart the X server also.
kdesktop_lock is spawned from kdesktop, so any debugging would likely involve terminating kdesktop and running kdesktop_lock under gdb from a terminal. When I have an answer to the above question I'll get back to you on how to debug further.
killed the 'kdesktop' process, ran 'gdb kdesktop_lock' in a terminal, output below.
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) q
Also, Did this bug first appear in RC2 or did it show up earlier?
It started when I upgraded to R14 fro 3.5.13.2, on 8/6/2014..thread "Wheezy upgrade to R14'. It was not this bad at first, it has progressively gotten worse,,till now it is unusable without disabling 'kdesktop_lock' binary.
Thanks!
Tim
Thanks for the reply.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Tuesday 02 December 2014 17:57:06 you wrote:
Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the
login
screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use screensaver
or
lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace if that would help and if someone could give directions on howto. I will file a bug with the backtrace.
Well that's strange. When you mention it crashing your Xorg session does that mean the Xorg server itself crashes (i.e. instantaneous dump back to the command line) or that TDE terminates leaving Xorg still running?
I do not think the x server crashed,I get dropped to the login prompt pretty quickly, does not seem like enough time to restart the X server also.
You'd be surprised how fast that login prompt shows up after an Xorg crash. ;-) However for now we can proceed under the assumption that it isn't one.
kdesktop_lock is spawned from kdesktop, so any debugging would likely involve terminating kdesktop and running kdesktop_lock under gdb from a terminal. When I have an answer to the above question I'll get back to you on how to debug further.
killed the 'kdesktop' process, ran 'gdb kdesktop_lock' in a terminal, output below.
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) q
You'll need to do something like this first... export DISPLAY=:0 then when you are in gdb, to start the program, enter: r <return>
All you did above was load the kdesktop_lock binary into GDB, then exited GDB. ;-)
Tim
On Tuesday 02 December 2014 19:44:55 you wrote:
On Tuesday 02 December 2014 17:57:06 you wrote:
Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the
login
screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use screensaver
or
lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace if that would help and if someone could give directions on howto. I will file a bug with the backtrace.
Well that's strange. When you mention it crashing your Xorg session does that mean the Xorg server itself crashes (i.e. instantaneous dump back to the command line) or that TDE terminates leaving Xorg still running?
I do not think the x server crashed,I get dropped to the login prompt pretty quickly, does not seem like enough time to restart the X server also.
You'd be surprised how fast that login prompt shows up after an Xorg crash. ;-) However for now we can proceed under the assumption that it isn't one.
kdesktop_lock is spawned from kdesktop, so any debugging would likely involve terminating kdesktop and running kdesktop_lock under gdb from a terminal. When I have an answer to the above question I'll get back to you on how to debug further.
killed the 'kdesktop' process, ran 'gdb kdesktop_lock' in a terminal, output below.
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) q
You'll need to do something like this first... export DISPLAY=:0 then when you are in gdb, to start the program, enter: r <return>
All you did above was load the kdesktop_lock binary into GDB, then exited GDB. ;-)
Tim
I should mention i know nothing of these matters..so beginners steps.
Logged into a session, in a terminal: 1. 'ps ax |grep kdesktop' 2. kill -9 <kdesktop PID> 3. ran 'gdb /opt/trinity/bin/kdsektop_lock'
output:
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock sniped license info
"Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) r Starting program: /opt/trinity/bin/kdesktop_lock [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [tdecore] Deleting stale lockfile /tmp/tde-pabi/kdesktop_lock_lockfile [tdecore] Deleting stale lockfile /tmp/tde-pabi/kdesktop_lock_lockfile [New Thread 0x7fffec0b9700 (LWP 19047)] [kdesktop_lock] Warning: unable to create control socket '/tmp/tdesocket-global/kdesktoplockcontrol-0'. Interactive logon modules may not function properly. [Thread 0x7fffec0b9700 (LWP 19047) exited] X Error: BadAccess (attempt to access private resource denied) 10 Major opcode: 2 Minor opcode: 0 Resource id: 0x1a00054 [Inferior 1 (process 19042) exited normally] (gdb) q"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Tuesday 02 December 2014 19:44:55 you wrote:
On Tuesday 02 December 2014 17:57:06 you wrote:
Debian Wheezy, Amd64, Nvidia quadro card, drivers from vender, dual monitors.
In my .xsession-errors files I can see numerous entries: "tdecore] Deleting stale lockfile /tmp/tde-pabiVcZK3y/kdesktop_lock_lockfile" This crashes my X session, ~ 1 minute uptime, dumps me back to the
login
screen, totaly unworkable.
I have been working around this issue because it only happens on 2 workstations with the same hardware specs, and drivers from Nvidia.
I remove '/opt/trinity/bin/kdesktop_lock', I do not use
screensaver
or
lock desktop, this works..until an update replaces the kdesktop_lock binary...this will stop eventually.
I read bugs 2222 & 2230, re kdesktop_lock, I could run a backtrace
if
that would help and if someone could give directions on howto. I
will
file a bug with the backtrace.
Well that's strange. When you mention it crashing your Xorg session does that mean the Xorg server itself crashes (i.e. instantaneous dump
back
to the command line) or that TDE terminates leaving Xorg still running?
I do not think the x server crashed,I get dropped to the login prompt pretty quickly, does not seem like enough time to restart the X server also.
You'd be surprised how fast that login prompt shows up after an Xorg crash. ;-) However for now we can proceed under the assumption that it isn't one.
kdesktop_lock is spawned from kdesktop, so any debugging would likely involve terminating kdesktop and running kdesktop_lock under gdb from
a
terminal. When I have an answer to the above question I'll get back
to
you on how to debug further.
killed the 'kdesktop' process, ran 'gdb kdesktop_lock' in a terminal, output below.
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) q
You'll need to do something like this first... export DISPLAY=:0 then when you are in gdb, to start the program, enter: r <return>
All you did above was load the kdesktop_lock binary into GDB, then exited GDB. ;-)
Tim
I should mention i know nothing of these matters..so beginners steps.
Logged into a session, in a terminal:
- 'ps ax |grep kdesktop'
- kill -9 <kdesktop PID>
- ran 'gdb /opt/trinity/bin/kdsektop_lock'
output:
pabi@tdewheezy:~$ gdb /opt/trinity/bin/kdesktop_lock sniped license info
"Reading symbols from /opt/trinity/bin/kdesktop_lock...Reading symbols from /usr/lib/debug/opt/trinity/bin/kdesktop_lock...done. done. (gdb) r Starting program: /opt/trinity/bin/kdesktop_lock [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [tdecore] Deleting stale lockfile /tmp/tde-pabi/kdesktop_lock_lockfile [tdecore] Deleting stale lockfile /tmp/tde-pabi/kdesktop_lock_lockfile [New Thread 0x7fffec0b9700 (LWP 19047)] [kdesktop_lock] Warning: unable to create control socket '/tmp/tdesocket-global/kdesktoplockcontrol-0'. Interactive logon modules may not function properly. [Thread 0x7fffec0b9700 (LWP 19047) exited] X Error: BadAccess (attempt to access private resource denied) 10 Major opcode: 2 Minor opcode: 0 Resource id: 0x1a00054 [Inferior 1 (process 19042) exited normally] (gdb) q"
No problem; I just wanted to let you know what commands you ran to make learning a bit easier. :-)
So far I don't see a crash, or indeed anything of interest beyond "X Error: BadAccess (attempt to access private resource denied) 10". Errors are not supposed to crash the X server though.
Can you clear out your ~/.xsession_errors file, load TDE (while allowing it to load kdesktop_lock normally), wait for the "crash" and then send the resultant (sanitized) ~/.xsession_errors file to either the list or me directly? Also helpful would be the output of dmesg, /var/log/syslog, and /var/log/Xorg.0.log.
If the TDE composition manager is active one thing you might try is temporarily disabling it (TDE Control Center-->Desktop-->Window Behaviour-->Tramslucency) to see if that works around the "crash".
Thanks!
Tim
On Wednesday 03 December 2014 06:27:16 you wrote:
snip
So far I don't see a crash, or indeed anything of interest beyond "X Error: BadAccess (attempt to access private resource denied) 10". Errors are not supposed to crash the X server though.
Can you clear out your ~/.xsession_errors file, load TDE (while allowing it to load kdesktop_lock normally), wait for the "crash" and then send the resultant (sanitized) ~/.xsession_errors file to either the list or me directly? Also helpful would be the output of dmesg, /var/log/syslog, and /var/log/Xorg.0.log.
If the TDE composition manager is active one thing you might try is temporarily disabling it (TDE Control Center-->Desktop-->Window Behaviour-->Tramslucency) to see if that works around the "crash".
Thanks!
Tim
I am sending you a private email with the various log files..thanks.
I realize that this is out of place, but I see trouble posts all the time, and I want to say that my Trinity-DE installations have been pretty much trouble free. Yes, there have been a couple of oopses, but in my cases they have been artifacts of the code base that Pearson inherited.
Thank you, Pearson Computing, for Trinity-DE. I really appreciate it.
Curt-
-
Curt Howland -
Greg Madden -
Timothy Pearson