I have one situation:

I have wifi, who likes to make trouble. When it starts to get angry, sometimes hangs KOrn. Shows some few empty notify dialogs, not closes it - and the CPU runs at 100%. When, in this case, was run a screen saver, it takes a long time. So long that desktop lock accedes to the logout. Very annoying.

But logout correctly first asks programs whether it is possible to end. Opened IRC in kopete allow me to stop logout process. But desktop lock then remains confused and dysfunctional (or crash?). Sometimes it causes dysfunctional ksmserver - it is not possible to logout correctly.

The result is the exact opposite of what desktop lock wanted addressed. Therefore, I think that logout in response to a slow start screen saver is incorrect behaviour. I did not mention that my machine is not modern, and so is sometimes slower anyway.

(In reply to comment #1)
> Therefore, I think that logout in response to a slow start screen saver is
> incorrect behaviour.

Agreed.  However, the session should not be logged out unless kdesktop_lock is forcibly terminated.  Can you verify that kdesktop_lock was not terminated by the OOM killer?  A glance at dmesg after you were forcibly logged out should show which processes were either terminated by the OOM killer or crashed.

Not always crashes - and if so never had OOM. Another time hangs so it stays running even after logout. I must use kill with SIGKILL to terminate it.

Have you observed this behaviour in the GIT builds?

(Odpověď na komentář #4)
> Have you observed this behaviour in the GIT builds?

On my work machines I use the official 3.5.13.1 (on Debian Squeeze). I can try to rebuild tdelibs and tdebase with patches 2771be62 and 4120a763, which I already backport into v3.5.13-sru branch.

I use GIT daily but I don't use the screen lock feature. If you provide me a basic test plan I'll do my best to help debug. As I leave and return to my desk a dozen times a day or more, I have ample opportunity to test the screen lock. I just need to know how to reproduce the problem.

(Odpověď na komentář #6)
> I use GIT daily but I don't use the screen lock feature. If you provide me a
> basic test plan I'll do my best to help debug. As I leave and return to my desk
> a dozen times a day or more, I have ample opportunity to test the screen lock.
> I just need to know how to reproduce the problem.

The problem is that the error manifests itself randomly. Usually, the "help" when the system is strongly burdened. So that screen saver started very slowly :)

I can nonetheless invoke the screen lock whenever I step away from the computer. Hardly a serious burden or inconvenience. I realize if I never witness the bug that my testing will not help much, but we'll never know unless I test. :)

Today I had another situation:

Exactly when the kdesktop_lock wanted to draw a background image and run screen saver, I moved the mouse. The desktop and all programs is returned - all programs are normally displayed, but the cursor was still with the "busy" indicator and input is grabbed by kdesktop_lock. The processor was running at 100% - for kdesktop_lock:

#0  __tzfile_compute (timer=1352560030, use_localtime=1, leap_correct=0xbfd2cc20, leap_hit=0xbfd2cc1c, tp=0xbfd2cc68) at tzfile.c:808
#1  0xb5edaec3 in __tz_convert (timer=0xbfd2cc9c, use_localtime=1, tp=0xbfd2cc68) at tzset.c:627
#2  0xb5ed955c in __localtime_r (t=0xbfd2cc9c, tp=0xbfd2cc68) at localtime.c:33
#3  0xb67c3a82 in QTime::currentTime (ct=0xbfd2cd2c, ts=Qt::LocalTime) at tools/qdatetime.cpp:1736
#4  0xb67c3aff in QTime::currentTime (ts=Qt::LocalTime) at tools/qdatetime.cpp:1652
#5  0xb67c3b3a in QTime::currentTime () at tools/qdatetime.cpp:1637
#6  0xb64b14bb in QEventLoop::processEvents (this=0x90a2330, flags=0, maxTime=3000) at kernel/qeventloop.cpp:259
#7  0xb6498c8e in QApplication::processEvents (this=0xbfd2d230, maxtime=3000) at kernel/qapplication.cpp:2696
#8  0xb6498cc5 in QApplication::processEvents (this=0xbfd2d230) at kernel/qapplication.cpp:2680
#9  0x08064e77 in LockProcess::startSaver() ()
#10 0x08065276 in LockProcess::defaultSave() ()
#11 0x0807a38b in main ()

It was unfortunate to see everything functioning normally, but the disease get to it. I could only kill kdesktop_lock from a text console.

I remember fixing that exact bug in GIT, so likely 3.5.13.1 is simply using the older broken code.

(Odpověď na komentář #10)
> I remember fixing that exact bug in GIT, so likely 3.5.13.1 is simply using the
> older broken code.

SAK and desktop lock are two things which have been backported perhaps the all patches. I would almost say that the code differs only because of renaming.

I just ran into this myself today, and grabbed a quick backtrace from a remote system:

0x00bf2416 in __kernel_vsyscall ()
(gdb) bt
#0  0x00bf2416 in __kernel_vsyscall ()
#1  0x0052c866 in gettimeofday () at ../sysdeps/unix/syscall-template.S:82
#2  0x0382d3fa in TQTime::currentTime (ct=0xbf8f02e8, ts=TQt::LocalTime) at tools/qdatetime.cpp:1728
#3  0x0382d4f0 in TQTime::currentTime (ts=TQt::LocalTime) at tools/qdatetime.cpp:1652
#4  0x0382d52a in TQTime::currentTime () at tools/qdatetime.cpp:1637
#5  0x03565849 in TQEventLoop::processEvents (this=0x9d69ee8, flags=0, maxTime=3000) at kernel/qeventloop.cpp:259
#6  0x03551f0c in TQApplication::processEvents (this=0xbf8f0a20, maxtime=3000) at kernel/qapplication.cpp:2760
#7  0x03551f43 in TQApplication::processEvents (this=0xbf8f0a20) at kernel/qapplication.cpp:2744
#8  0x0805b8de in _start ()
(gdb) q

Attempting to step through the application results in this:

__offtime (t=0xbf8f026c, offset=-21600, tp=0xbf8f0238) at offtime.c:34
34      offtime.c: No such file or directory.
(gdb) n
38      in offtime.c
(gdb) n
34      in offtime.c
(gdb) n
38      in offtime.c
(gdb)
34      in offtime.c
(gdb)
38      in offtime.c
(gdb)
39      in offtime.c
(gdb)
41      in offtime.c
(gdb)
46      in offtime.c
(gdb)
51      in offtime.c
(gdb)
52      in offtime.c
(gdb)
53      in offtime.c
(gdb)
54      in offtime.c
(gdb)
56      in offtime.c
(gdb)
54      in offtime.c
(gdb)
56      in offtime.c
(gdb)
57      in offtime.c
(gdb)
56      in offtime.c
(gdb)
57      in offtime.c
(gdb)
59      in offtime.c
(gdb)
64      in offtime.c
(gdb)
67      in offtime.c
(gdb)
71      in offtime.c
(gdb)
72      in offtime.c
(gdb)
71      in offtime.c
(gdb)
72      in offtime.c
(gdb)
71      in offtime.c
(gdb)
70      in offtime.c
(gdb)
71      in offtime.c
(gdb)
70      in offtime.c
(gdb)
71      in offtime.c
(gdb)
73      in offtime.c
(gdb)
71      in offtime.c
(gdb)
72      in offtime.c
(gdb)
70      in offtime.c
(gdb)
64      in offtime.c
(gdb)
83      in offtime.c
(gdb)
75      in offtime.c
(gdb)
83      in offtime.c
(gdb)
75      in offtime.c
(gdb)
83      in offtime.c
(gdb)
82      in offtime.c
(gdb)
83      in offtime.c
(gdb)
84      in offtime.c
(gdb)
87      in offtime.c
(gdb)
86      in offtime.c
(gdb)
90      in offtime.c
(gdb)
88      in offtime.c
(gdb)
87      in offtime.c
(gdb)
88      in offtime.c
(gdb)
90      in offtime.c
(gdb)

__tz_convert (timer=0xbf8f026c, use_localtime=1, tp=0xbf8f0238) at tzset.c:649
649     tzset.c: No such file or directory.
(gdb)
654     in tzset.c
(gdb)
657     in tzset.c
(gdb)
__localtime_r (t=0xbf8f026c, tp=0xbf8f0238) at localtime.c:34
34      localtime.c: No such file or directory.
(gdb)
TQTime::currentTime (ct=0xbf8f02e8, ts=TQt::LocalTime) at tools/qdatetime.cpp:1747
1747    tools/qdatetime.cpp: No such file or directory.
(gdb)
1761    in tools/qdatetime.cpp
(gdb)
1747    in tools/qdatetime.cpp
(gdb) bt
#0  TQTime::currentTime (ct=0xbf8f02e8, ts=TQt::LocalTime) at tools/qdatetime.cpp:1747
#1  0x0382d4f0 in TQTime::currentTime (ts=TQt::LocalTime) at tools/qdatetime.cpp:1652
#2  0x0382d52a in TQTime::currentTime () at tools/qdatetime.cpp:1637
#3  0x03565849 in TQEventLoop::processEvents (this=0x9d69ee8, flags=0, maxTime=3000) at kernel/qeventloop.cpp:259
#4  0x03551f0c in TQApplication::processEvents (this=0xbf8f0a20, maxtime=3000) at kernel/qapplication.cpp:2760
#5  0x03551f43 in TQApplication::processEvents (this=0xbf8f0a20) at kernel/qapplication.cpp:2744
#6  0x0805b8de in _start ()
(gdb) n
1760    in tools/qdatetime.cpp
(gdb)
1747    in tools/qdatetime.cpp
(gdb)
1760    in tools/qdatetime.cpp
(gdb)
1761    in tools/qdatetime.cpp
(gdb)
TQTime::currentTime (ts=TQt::LocalTime) at tools/qdatetime.cpp:1654
1654    in tools/qdatetime.cpp
(gdb)
TQTime::currentTime () at tools/qdatetime.cpp:1638
1638    in tools/qdatetime.cpp
(gdb)
1637    in tools/qdatetime.cpp
(gdb)
TQTime::currentTime () at tools/qdatetime.cpp:1638
1638    in tools/qdatetime.cpp
(gdb)
TQEventLoop::processEvents (this=0x9d69ee8, flags=0, maxTime=3000) at kernel/qeventloop.cpp:260
260     kernel/qeventloop.cpp: No such file or directory.
(gdb)
261     in kernel/qeventloop.cpp
(gdb)
266     in kernel/qeventloop.cpp
(gdb)
TQApplication::processEvents (this=0xbf8f0a20, maxtime=3000) at kernel/qapplication.cpp:2761
2761    kernel/qapplication.cpp: No such file or directory.
(gdb)
TQApplication::processEvents (this=0xbf8f0a20) at kernel/qapplication.cpp:2745
2745    in kernel/qapplication.cpp
(gdb)
0x0805b8de in _start ()
(gdb)
Single stepping until exit from function _start,
which has no line number information.

Needless to say I have never seen this kind of behaviour from an application before!

This test is on Precise with TDE R14 GIT.  What version of Ubuntu have you observed this failure on?

Your backtrace has additional information mine did not.  It looks like the problem is related to this code in lockprocess.cc:

while ((backingPixmap.isNull()) && (mEnsureScreenHiddenTimer->isActive())) {
    kapp->processEvents();
}

Raising priority to BLOCKER.

I have committed a patch in GIT hash 4de72a5 that should prevent the observed lockup.  Please reopen this bug report if you experience additional crashes or hangs!

Since incorporation patch 4de72a5 I have not observed hangs.
But yesterday I again saw the "crash".
In .xsession-errors is repeated:

[kdesktop_lock] WARNING: A fatal exception was encountered.  Trapping and
ignoring it so as not to compromise desktop security...

Unfortunately I can not add much more informations. It is certain that this is not a consequence of OOM. The "crash" occurred while the machine was unused. After waking up the monitor was displayed only the background image. It was then necessary to manually kill kdesktop_lock, which subsequently led to logout.

(In reply to comment #15)
> Since incorporation patch 4de72a5 I have not observed hangs.
> But yesterday I again saw the "crash".
> In .xsession-errors is repeated:
> 
> [kdesktop_lock] WARNING: A fatal exception was encountered.  Trapping and
> ignoring it so as not to compromise desktop security...

That message is the result of a trapped SIGSEGV or similar.  We need to spit out a backtrace in addition to that warning message so that the offending code can be found and fixed.  Let me work on that and get a package set built that includes the backtrace code, then when kdesktop_lock crashes again you will be able to attach a usable backtrace here for analysis.

Stack trace printing added in GIT hash 786e248.  Please recompile/reinstall tdebase from GIT and post the backtrace from .xsession_errors when kdesktop_lock hangs up again.

Thanks!

With commit 786e248c I observe that kdesktop_lock sometimes remains in a state:

# 0 0x00007f47f690753a in sigsuspend () from / lib/libc.so.6
# 1 0x000000000043461f in main ()

But to .xsession-errors not write anything.
After quit gdb process disappears.
Any ideas?

When I hybernate my laptop, it sometime happens that there appears two unlock screen windows over each other. In this case, after waking up both unlock windows are closed, I can not unlock the screen, kdesktop_lock load processor to 100% and the only way is to kill the session.

Because it happened to me a few times, I attach three backtraces.

Created attachment 1073 [details]
two unlock screen windows backtrace

Created attachment 1074 [details]
two unlock screen windows backtrace 1

Created attachment 1075 [details]
two unlock screen windows backtrace 2

(In reply to comment #19)
> When I hybernate my laptop, it sometime happens that there appears two unlock
> screen windows over each other. In this case, after waking up both unlock
> windows are closed, I can not unlock the screen, kdesktop_lock load processor
> to 100% and the only way is to kill the session.
> 
> Because it happened to me a few times, I attach three backtraces.

My best guess is a race condition between the two possible code paths that are able to call checkPass(); this has been worked around in GIT hash 3e5e79f.

Please let me know if this actually resolves the problem, as I have been unable to confirm due to s2disk failing on my test laptop.

(In reply to comment #19)
> When I hybernate my laptop, it sometime happens that there appears two unlock
> screen windows over each other. In this case, after waking up both unlock
> windows are closed, I can not unlock the screen, kdesktop_lock load processor
> to 100% and the only way is to kill the session.
> 
> Because it happened to me a few times, I attach three backtraces.

My best guess is a race condition between the two possible code paths that are able to call checkPass(); this has been worked around in GIT hash 3e5e79f.

Please let me know if this actually resolves the problem, as I have been unable to confirm due to s2disk failing on my test laptop.

(In reply to comment #24)
> My best guess is a race condition between the two possible code paths that are
> able to call checkPass(); this has been worked around in GIT hash 3e5e79f.
> 
> Please let me know if this actually resolves the problem, as I have been unable
> to confirm due to s2disk failing on my test laptop.
This does not resolve the problem:
- Like for the problem appear for me from original 3.5.13.1 version but my problem only display screen saver or black display impossible to exit from that by any keyboard or mouse event.
- Next I have update to last 3.5.13-sru state and get the problem also.
- Next I have add your path 3e5e79f and observe already all this two problem.

I think all the problems grow from changes 3.5.13 -> 3.5.13.1 and I will try revert all changes into kdesktop/lock. On version 3.5.13 I have not any like problems!

(In reply to comment #25)
> This does not resolve the problem:
> - Like for the problem appear for me from original 3.5.13.1 version but my
> problem only display screen saver or black display impossible to exit from that
> by any keyboard or mouse event.
> - Next I have update to last 3.5.13-sru state and get the problem also.
> - Next I have add your path 3e5e79f and observe already all this two problem.
And yet one note. The problems more often appear on high loaded system.

(In reply to comment #26)
> (In reply to comment #25)
> > This does not resolve the problem:
> > - Like for the problem appear for me from original 3.5.13.1 version but my
> > problem only display screen saver or black display impossible to exit from that
> > by any keyboard or mouse event.
> > - Next I have update to last 3.5.13-sru state and get the problem also.
> > - Next I have add your path 3e5e79f and observe already all this two problem.
> And yet one note. The problems more often appear on high loaded system.

Strange!  The patch in 4de72a5 should have resolved that problem.

Can you break into kdesktop_lock while it is hung with gdb (e.g. with a virtual terminal or over ssh) and post a backtrace?

Thanks!

(Odpověď na komentář #27)
> Strange!  The patch in 4de72a5 should have resolved that problem.
> 
> Can you break into kdesktop_lock while it is hung with gdb (e.g. with a virtual
> terminal or over ssh) and post a backtrace?
> 
> Thanks!

I can confirm that since backport 4de72a5 and 786e248 I not observed hangs or crash. At least not in such a way that the system is arbitrarily logout me. I never noticed that it was listed backtrace automatic - as it should provide a patch in 786e248. Once I happened to screensaver still running undisturbed and it can not be interrupted. However, during this situacion subsequently was not possible even login on a text console - probably some other problem with system.

A few days ago I noticed a problem when remote access to the desktop published using x11vnc. Constantly starts screensaver, but after a while it stopped starting screensaver - completely. However, when I wanted the same test on a virtual machine, the behavior was just as bad, but after manual start screensaver its functioning again restored.

Note: Now I test patch in 3e5e79f - soon I'll backport it into v3.5.13-sru branch.

(In reply to comment #27)
> > > - Next I have update to last 3.5.13-sru state and get the problem also.
> > > - Next I have add your path 3e5e79f and observe already all this two problem.
> > And yet one note. The problems more often appear on high loaded system.
> Strange!  The patch in 4de72a5 should have resolved that problem.
The patch 4de72a5 and 786e248 already used for me but it does not fix the problems.

> Can you break into kdesktop_lock while it is hung with gdb (e.g. with a virtual
> terminal or over ssh) and post a backtrace?
OK I will try that.

(In reply to comment #29)
> > Can you break into kdesktop_lock while it is hung with gdb (e.g. with a virtual
> > terminal or over ssh) and post a backtrace?
> OK I will try that.
In the time kdesktop_lock hang and memory leak up to 800MB.

[root@roman apt]# ps -A | grep kdesktop_lock
15420 ?        00:04:41 kdesktop_lock
[root@roman apt]# gdb --pid 15420
(gdb) bt
#0  0x0809764d in bfd_calc_gnu_debuglink_crc32 ()
#1  0x080976c0 in separate_debug_file_exists ()
#2  0x080979bd in bfd_follow_gnu_debuglink ()
#3  0x0811f28c in find_line ()
#4  0x080b9da5 in _bfd_elf_find_nearest_line ()
#5  0x0807f3aa in find_address_in_section (abfd=0x39d71a70, section=0x3b1e6938, data=0x0)
    at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:118
#6  0x08098607 in bfd_map_over_sections ()
#7  0x0807f529 in translate_addresses_buf (file_name=<value optimized out>, addr=0x8157468, naddr=1)
    at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:152
#8  process_file (file_name=<value optimized out>, addr=0x8157468, naddr=1)
    at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:219
#9  0x0807f7a9 in backtrace_symbols (buffer=0xbfc6ff58, size=10) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:282
#10 0x0806430a in print_trace () at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:142
#11 0x0806438f in segv_handler () at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:156
#12 <signal handler called>
#13 QWidget::frameGeometry (this=0x5f434c2f) at kernel/qwidget.cpp:6062
#14 0x0806aeff in LockProcess::slotMouseActivity (this=0xbfc70b1c, event=0xbfc709cc)
    at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:2498
#15 0x0806f11f in LockProcess::qt_invoke (this=0xbfc70b1c, _id=68, _o=0xbfc70668)
    at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/lockprocess.moc:166
#16 0xb6791045 in QObject::activate_signal (this=0xbfc70fc0, clist=0x81c20b0, o=0xbfc70668) at kernel/qobject.cpp:2383
#17 0x0807c2f0 in MyApp::mouseInteraction (this=0xbfc70fc0, t0=0xbfc709cc)
    at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/main.moc:111
#18 0x0807c4ef in MyApp::x11EventFilter (this=0xbfc70fc0, ev=0xbfc709cc) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:73
#19 0xb6704e13 in qt_x11EventFilter (ev=0xbfc709cc) at kernel/qapplication_x11.cpp:410
#20 0xb6710178 in QApplication::x11ProcessEvent (this=0xbfc70fc0, event=0xbfc709cc) at kernel/qapplication_x11.cpp:3396
#21 0xb671deba in QEventLoop::processEvents (this=0x8196900, flags=4) at kernel/qeventloop_x11.cpp:195
#22 0xb676230f in QEventLoop::enterLoop (this=0x8196900) at kernel/qeventloop.cpp:201
#23 0xb67622a0 in QEventLoop::exec (this=0x8196900) at kernel/qeventloop.cpp:148
#24 0xb675400c in QApplication::exec (this=0xbfc70fc0) at kernel/qapplication.cpp:2762
#25 0x0807d31d in main (argc=134675760, argv=0x8063ff0) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:439

After SIGSEGV no one reaction and possible kdesktop_lock hang on self backtrace_symbols.c processing.

(In reply to comment #30)
> (In reply to comment #29)
> > > Can you break into kdesktop_lock while it is hung with gdb (e.g. with a virtual
> > > terminal or over ssh) and post a backtrace?
> > OK I will try that.
> In the time kdesktop_lock hang and memory leak up to 800MB.
> 
> [root@roman apt]# ps -A | grep kdesktop_lock
> 15420 ?        00:04:41 kdesktop_lock
> [root@roman apt]# gdb --pid 15420
> (gdb) bt
> #0  0x0809764d in bfd_calc_gnu_debuglink_crc32 ()
> #1  0x080976c0 in separate_debug_file_exists ()
> #2  0x080979bd in bfd_follow_gnu_debuglink ()
> #3  0x0811f28c in find_line ()
> #4  0x080b9da5 in _bfd_elf_find_nearest_line ()
> #5  0x0807f3aa in find_address_in_section (abfd=0x39d71a70, section=0x3b1e6938,
> data=0x0)
>     at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:118
> #6  0x08098607 in bfd_map_over_sections ()
> #7  0x0807f529 in translate_addresses_buf (file_name=<value optimized out>,
> addr=0x8157468, naddr=1)
>     at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:152
> #8  process_file (file_name=<value optimized out>, addr=0x8157468, naddr=1)
>     at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:219
> #9  0x0807f7a9 in backtrace_symbols (buffer=0xbfc6ff58, size=10) at
> /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/backtrace_symbols.c:282
> #10 0x0806430a in print_trace () at
> /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:142
> #11 0x0806438f in segv_handler () at
> /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:156
> #12 <signal handler called>
> #13 QWidget::frameGeometry (this=0x5f434c2f) at kernel/qwidget.cpp:6062
> #14 0x0806aeff in LockProcess::slotMouseActivity (this=0xbfc70b1c,
> event=0xbfc709cc)
>     at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:2498
> #15 0x0806f11f in LockProcess::qt_invoke (this=0xbfc70b1c, _id=68,
> _o=0xbfc70668)
>     at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/lockprocess.moc:166
> #16 0xb6791045 in QObject::activate_signal (this=0xbfc70fc0, clist=0x81c20b0,
> o=0xbfc70668) at kernel/qobject.cpp:2383
> #17 0x0807c2f0 in MyApp::mouseInteraction (this=0xbfc70fc0, t0=0xbfc709cc)
>     at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/main.moc:111
> #18 0x0807c4ef in MyApp::x11EventFilter (this=0xbfc70fc0, ev=0xbfc709cc) at
> /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:73
> #19 0xb6704e13 in qt_x11EventFilter (ev=0xbfc709cc) at
> kernel/qapplication_x11.cpp:410
> #20 0xb6710178 in QApplication::x11ProcessEvent (this=0xbfc70fc0,
> event=0xbfc709cc) at kernel/qapplication_x11.cpp:3396
> #21 0xb671deba in QEventLoop::processEvents (this=0x8196900, flags=4) at
> kernel/qeventloop_x11.cpp:195
> #22 0xb676230f in QEventLoop::enterLoop (this=0x8196900) at
> kernel/qeventloop.cpp:201
> #23 0xb67622a0 in QEventLoop::exec (this=0x8196900) at
> kernel/qeventloop.cpp:148
> #24 0xb675400c in QApplication::exec (this=0xbfc70fc0) at
> kernel/qapplication.cpp:2762
> #25 0x0807d31d in main (argc=134675760, argv=0x8063ff0) at
> /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:439
> 
> After SIGSEGV no one reaction and possible kdesktop_lock hang on self
> backtrace_symbols.c processing.

Interesting.  Can yuo please post the lockprocess.cc that corresponds with this backtrace?  I need to know exactly which line of code is causing the segfault.

Thanks!

Tim

Created attachment 1077 [details]
LockProcess.cc

(In reply to comment #31)
> Interesting.  Can yuo please post the lockprocess.cc that corresponds with this
> backtrace?  I need to know exactly which line of code is causing the segfault.
Included but into that seen strange backtrace into frameGeometry().

(In reply to comment #32)
> Created attachment 1077 [details]
> LockProcess.cc
> 
> (In reply to comment #31)
> > Interesting.  Can yuo please post the lockprocess.cc that corresponds with this
> > backtrace?  I need to know exactly which line of code is causing the segfault.
> Included but into that seen strange backtrace into frameGeometry().

The only possibility I can think of is that the dialog was deleted but its pointer was not removed from the list of dialogs.  I will need to look into this further; is there any known way to make the bug consistently appear or is it fairly random/sporadic?

(Odpověď na komentář #33)
> (In reply to comment #32)
> > Created attachment 1077 [details] [details]
> > LockProcess.cc
> > 
> > (In reply to comment #31)
> > > Interesting.  Can yuo please post the lockprocess.cc that corresponds with this
> > > backtrace?  I need to know exactly which line of code is causing the segfault.
> > Included but into that seen strange backtrace into frameGeometry().
> 
> The only possibility I can think of is that the dialog was deleted but its
> pointer was not removed from the list of dialogs.  I will need to look into
> this further; is there any known way to make the bug consistently appear or is
> it fairly random/sporadic?

In my cases it was sporadic.
That's more uncomfortable then.

(In reply to comment #34)
> (Odpověď na komentář #33)
> > (In reply to comment #32)
> > > Created attachment 1077 [details] [details] [details]
> > > LockProcess.cc
> > > 
> > > (In reply to comment #31)
> > > > Interesting.  Can yuo please post the lockprocess.cc that corresponds with this
> > > > backtrace?  I need to know exactly which line of code is causing the segfault.
> > > Included but into that seen strange backtrace into frameGeometry().
> > 
> > The only possibility I can think of is that the dialog was deleted but its
> > pointer was not removed from the list of dialogs.  I will need to look into
> > this further; is there any known way to make the bug consistently appear or is
> > it fairly random/sporadic?
> 
> In my cases it was sporadic.
> That's more uncomfortable then.

In my Qt sources frameGeometry is nowhere near line 6062; what version of Qt or TQt3 do you have installed?

Thanks!

(In reply to comment #35)
> In my Qt sources frameGeometry is nowhere near line 6062; what version of Qt or
> TQt3 do you have installed?
I also have think about that yesterday and saw to QT3 changes http://git.trinitydesktop.org/cgit/qt3/log/?h=origin/v3.5.13-sru.

Next I have made fresh QT3 build for me.

Now I have not seen the problem and also seems gone problem on KJobViewer exit (http://bugs.trinitydesktop.org/show_bug.cgi?id=1362), which into QString::isNull() function.

I will further follow the problems for several days.

(In reply to comment #36)
> Now I have not seen the problem and also seems gone problem on KJobViewer exit
> (http://bugs.trinitydesktop.org/show_bug.cgi?id=1362), which into
> QString::isNull() function.
After four days I have not observe the bug but have test on 3 special and 4 work PC.

But second bug 1362 still meet. For that I have drop all my fix attempts and will continue trace.

OK, I'm marking this as resolved for the time being.  If anyone experiences any further issues with kdesktop_lock hanging up please reopen this bug report with the new information.

Thanks for reporting!

(In reply to comment #38)
> OK, I'm marking this as resolved for the time being.  If anyone experiences any
> further issues with kdesktop_lock hanging up please reopen this bug report with
> the new information.

The bug possible reproduced into other context by bug http://bugs.trinitydesktop.org/show_bug.cgi?id=1394.

After ksmserver crash and drkonki the bug processing kdesktop_lock left hang, some time into several items.

Next exit from kdm do not cause exit from system.

BT for kdesktop_lock:
(gdb) bt
#0  0xb62c4e12 in do_sigsuspend (set=0xbfbc5e04) at ../sysdeps/unix/sysv/linux/sigsuspend.c:63
#1  __sigsuspend (set=0xbfbc5e04) at ../sysdeps/unix/sysv/linux/sigsuspend.c:74
#2  0x0807d15b in main (argc=Cannot access memory at address 0x8
) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:358

I think the bug into screen lock disabling on movie play into Kaffeine. The function I see do not work from 3.5.12 and up to current version.

(In reply to comment #38)
> OK, I'm marking this as resolved for the time being.  If anyone experiences any
> further issues with kdesktop_lock hanging up please reopen this bug report with
> the new information.
Now I again see the bug, kdesktop_lock hang and leak:
#0  0xb6290f4b in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0xb6290d96 in __sleep (seconds=<value optimized out>) at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  <signal handler called>
#3  QWidget::frameGeometry (this=0x10) at kernel/qwidget.cpp:6062
#4  0x0806aeff in LockProcess::slotMouseActivity (this=0xbfc3346c, event=0xbfc3331c)
    at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/lockprocess.cc:2498
#5  0x0806f11f in LockProcess::qt_invoke (this=0xbfc3346c, _id=68, _o=0xbfc32f58)
    at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/lockprocess.moc:166
#6  0xb67dd23b in QObject::activate_signal (this=0xbfc33910, clist=0x81c2ed0, o=0xbfc32f58) at kernel/qobject.cpp:2383
#7  0x0807c2f0 in MyApp::mouseInteraction (this=0xbfc33910, t0=0xbfc3331c)
    at /usr/src/debug/kdebase-3.5.13.1/BUILD/kdesktop/lock/main.moc:111
#8  0x0807c4ef in MyApp::x11EventFilter (this=0xbfc33910, ev=0xbfc3331c) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:73
#9  0xb6750e83 in qt_x11EventFilter (ev=0xbfc3331c) at kernel/qapplication_x11.cpp:410
#10 0xb675c200 in QApplication::x11ProcessEvent (this=0xbfc33910, event=0xbfc3331c) at kernel/qapplication_x11.cpp:3403
#11 0xb6769fe2 in QEventLoop::processEvents (this=0x8196a60, flags=4) at kernel/qeventloop_x11.cpp:195
#12 0xb67ae4ff in QEventLoop::enterLoop (this=0x8196a60) at kernel/qeventloop.cpp:201
#13 0xb67ae490 in QEventLoop::exec (this=0x8196a60) at kernel/qeventloop.cpp:148
#14 0xb67a01f0 in QApplication::exec (this=0xbfc33910) at kernel/qapplication.cpp:2762
#15 0x0807d31d in main (argc=134675760, argv=0x8063ff0) at /usr/src/debug/kdebase-3.5.13.1/kdesktop/lock/main.cc:439

(In reply to comment #40)
> (In reply to comment #38)
> > OK, I'm marking this as resolved for the time being.  If anyone experiences any
> > further issues with kdesktop_lock hanging up please reopen this bug report with
> > the new information.
> Now I again see the bug, kdesktop_lock hang and leak:
I have second reproducing for the bug.

I looked into kdesktop/lock/lockprocess.cc and I noticed one thing: between "mHackProc.kill(SIGSTOP);" and "mSuspended = true;" is a lot of time, including "usleep(100000);"

It is possible that during this time may other signals come and be in an inconsistent state of mSuspended? It would help to set mSuspended = true; immediately after SIGSTOP?

(In reply to comment #42)
> I looked into kdesktop/lock/lockprocess.cc and I noticed one thing: between
> "mHackProc.kill(SIGSTOP);" and "mSuspended = true;" is a lot of time, including
> "usleep(100000);"
> 
> It is possible that during this time may other signals come and be in an
> inconsistent state of mSuspended? It would help to set mSuspended = true;
> immediately after SIGSTOP?

IIRC much of the code involving the SyncX calls and the usleep(100000) was only added due to the old-style lock screen malfunctioning on certain graphics drivers.  With the new-style lock screen this code is disabled.

...which brings up the question I completely forgot to ask.  Is anyone experiencing the bug when the new-style modal dialogs are in use instead of the old-style undecorated lock dialog that popped up in front of the active saver?

(Odpověď na komentář #43)
> IIRC much of the code involving the SyncX calls and the usleep(100000) was only
> added due to the old-style lock screen malfunctioning on certain graphics
> drivers.  With the new-style lock screen this code is disabled.
> 
> ...which brings up the question I completely forgot to ask.  Is anyone
> experiencing the bug when the new-style modal dialogs are in use instead of the
> old-style undecorated lock dialog that popped up in front of the active saver?

Everywhere I use the new-style modal dialogs - with decorations.

(In reply to comment #44)
> (Odpověď na komentář #43)
> > IIRC much of the code involving the SyncX calls and the usleep(100000) was only
> > added due to the old-style lock screen malfunctioning on certain graphics
> > drivers.  With the new-style lock screen this code is disabled.
> > 
> > ...which brings up the question I completely forgot to ask.  Is anyone
> > experiencing the bug when the new-style modal dialogs are in use instead of the
> > old-style undecorated lock dialog that popped up in front of the active saver?
> 
> Everywhere I use the new-style modal dialogs - with decorations.

And you have experienced the crash/hang in slotMouseActivity?

(Odpověď na komentář #45)
> And you have experienced the crash/hang in slotMouseActivity?

Currently, a longer time I not noticed crashes. But it happens that kdesktop_lock is stopped in sigsuspend - as described in the comment 39.

In this case, is not activated screen saver and desktop locking. Attempt to lock screen using Ctrl+Alt+L then causes that desktop become inaccessible - although the screen is not locked -  is only displayed busy cursor.

Created attachment 1104 [details]
Fix race condition with SIGSTOP in kdesktop_lock

Because I have a suspicion to race condition (see comment 42), I created a patch that moves setting mSuspended closer to sending signal SIGSTOP.

On the machine where I observed this problem, a patch is tested throughout the week - so far successfully. Machine is continuously turned on, the user is logged in continuously. At idle, the screen saver starts, and then turned off monitor.

Please can someone else test whether the patch will help in your case?

Although the patch from attachment 1104 [details] for me solves the problems with SIGSTOP (I incorporate it soon), today I saw the kdesktop_lock crash => so at first showed me the backtrace generation integrated in kdesktop_lock:

[kdesktop_lock] WARNING: A fatal exception was encountered.  Trapping and ignoring it so as not to compromise desktop security...
[kdesktop_lock] Obtained 10 stack frames.
[kdesktop_lock] lockprocess.cc:147	print_trace()
[kdesktop_lock] lockprocess.cc:163	segv_handler()
[kdesktop_lock] [0xffffffffffffe400] ??() ??:0
[kdesktop_lock] qwidget.h:757	QWidget::testWFlags()
[kdesktop_lock] qvaluelist.h:566	QValueList<QWidget*>::detach()
[kdesktop_lock] lockprocess.moc:166	LockProcess::qt_invoke()
[kdesktop_lock] qobject.cpp:2384	QObject::activate_signal()
[kdesktop_lock] qucom_p.h:131	~QUObject()
[kdesktop_lock] main.cc:70	MyApp::x11EventFilter()
[kdesktop_lock] qapplication_x11.cpp:410	qt_x11EventFilter()

On the screen does not appear anything - it was completely black. Backtrace is in .xsession-errors repeated over and over again before I kdesktop_lock killed.

Comment on attachment 1104 [details]
Fix race condition with SIGSTOP in kdesktop_lock

Pushed to GIT in hash c03540e9 and also into v3.5.13-sru branch.

(In reply to comment #47)
> Please can someone else test whether the patch will help in your case?
I have apply your patch and have not observe more crash for 8 days. But I have been seen twice long appearing for lock dialog, up to 90 seconds.

I think that reason is into the patch "Attempt to work around issue described in Bug 1288":
while ((backingPixmap.isNull()) && (mEnsureScreenHiddenTimer->isActive())) {
-				kapp->processEvents();
+				kapp->eventLoop()->processEvents(TQEventLoop::ExcludeUserInput);
+
+				// HACK
+				// Work around an issue with the underlying system whereby the TQTimer sometimes fails to time out!
+				// This issue was reported in Bug #1288
+				usleep(100);
+				exitTimer++;
+				if (exitTimer > (DESKTOP_WALLPAPER_OBTAIN_TIMEOUT_MS*10)) {
+					break;
+				}
 			}
Prospective time for the cycle terminate is 3s but in real usleep() do not hold too short time and will hold minimum 500us. Next, all other function consume not zero time also.

(Odpověď na komentář #48)
> [kdesktop_lock] WARNING: A fatal exception was encountered.  Trapping and
> ignoring it so as not to compromise desktop security...
> [kdesktop_lock] Obtained 10 stack frames.
> [kdesktop_lock] lockprocess.cc:147    print_trace()
> [kdesktop_lock] lockprocess.cc:163    segv_handler()
> [kdesktop_lock] [0xffffffffffffe400] ??() ??:0
> [kdesktop_lock] qwidget.h:757    QWidget::testWFlags()
> [kdesktop_lock] qvaluelist.h:566    QValueList<QWidget*>::detach()
> [kdesktop_lock] lockprocess.moc:166    LockProcess::qt_invoke()
> [kdesktop_lock] qobject.cpp:2384    QObject::activate_signal()
> [kdesktop_lock] qucom_p.h:131    ~QUObject()
> [kdesktop_lock] main.cc:70    MyApp::x11EventFilter()
> [kdesktop_lock] qapplication_x11.cpp:410    qt_x11EventFilter()

I looked into lockprocess.moc - line 166 for me contains:

case 22: slotMouseActivity((XEvent*)static_QUType_ptr.get(_o+1)); break;

Please, how can I help more with the unveiling of the problem?

(In reply to comment #51)
> (Odpověď na komentář #48)
> > [kdesktop_lock] WARNING: A fatal exception was encountered.  Trapping and
> > ignoring it so as not to compromise desktop security...
> > [kdesktop_lock] Obtained 10 stack frames.
> > [kdesktop_lock] lockprocess.cc:147    print_trace()
> > [kdesktop_lock] lockprocess.cc:163    segv_handler()
> > [kdesktop_lock] [0xffffffffffffe400] ??() ??:0
> > [kdesktop_lock] qwidget.h:757    QWidget::testWFlags()
> > [kdesktop_lock] qvaluelist.h:566    QValueList<QWidget*>::detach()
> > [kdesktop_lock] lockprocess.moc:166    LockProcess::qt_invoke()
> > [kdesktop_lock] qobject.cpp:2384    QObject::activate_signal()
> > [kdesktop_lock] qucom_p.h:131    ~QUObject()
> > [kdesktop_lock] main.cc:70    MyApp::x11EventFilter()
> > [kdesktop_lock] qapplication_x11.cpp:410    qt_x11EventFilter()
> 
> I looked into lockprocess.moc - line 166 for me contains:
> 
> case 22: slotMouseActivity((XEvent*)static_QUType_ptr.get(_o+1)); break;
> 
> Please, how can I help more with the unveiling of the problem?

Do you use the SAK feature?  More importantly, has anyone observed the hang/trapped crash when they are NOT using the SAK feature?

My best guess is still that a TQWidget somewhere is being deleted behind the lock process's back, and on subsequent reference the process crashes.  Valgrind would be helpful here, but it is impractical to use for the long durations observed between crashes.

Tim

Created attachment 1110 [details]
Fix incorrect dialog existence checks

This is interesting.  On looking carefully at the mDialogs member variable and therefore the TQValueStack class, I ran across this line in the documentation:

"T & QValueList::first  Returns a reference to the first item. If the list contains no first item (i.e. isEmpty() returns TRUE), the return value is undefined. "

From what I can tell the original code in the lock process utilized mDialogs.first() as a check for the existence of any dialogs whatsoever; while in most cases an empty mDialogs will return NULL, and thus not crash, it is not guaranteed to do so.

If my reasoning is correct, the attached patch should resolve these infuriating crashes once and for all!

Comment on attachment 1110 [details]
Fix incorrect dialog existence checks

Pushed to GIT in hash 7ca0422 as there is no obvious reason not to do so.

I'm marking this as resolved for the time being. If anyone experiences any further issues, please reopen this bug report.

Although it looked promising again today I noticed a problem with a stop at sigsuspend. Any ideas?

Additional information: SAK is on this machine turned off.

(In reply to comment #56)
> Although it looked promising again today I noticed a problem with a stop at
> sigsuspend. Any ideas?

What exactly happens in this case?  Do you see two kdesktop_lock processes with one suspended, or do you just see the one suspended process with kdesktop_lock subsequently failing to work?

The reason I ask is that kdesktop_lock normally suspends itself after registering hooks to obtain the desktop wallpaper and waits for kdesktop to signal it to wake back up; this means that there should *always* be one suspended (process state 'Z') kdesktop_lock process per running kdesktop process.

Tim

(Odpověď na komentář #58)
> (In reply to comment #56)
> > Although it looked promising again today I noticed a problem with a stop at
> > sigsuspend. Any ideas?
> 
> What exactly happens in this case?  Do you see two kdesktop_lock processes with
> one suspended, or do you just see the one suspended process with kdesktop_lock
> subsequently failing to work?
> 
> The reason I ask is that kdesktop_lock normally suspends itself after
> registering hooks to obtain the desktop wallpaper and waits for kdesktop to
> signal it to wake back up; this means that there should *always* be one
> suspended (process state 'Z') kdesktop_lock process per running kdesktop
> process.
> 
> Tim

I see one process in the 'S'. When I try to gdb, I see the waiting in the sigsuspend - as mentioned above. Screensaver is not activated, the screen remains accessible - only after a period of inactivity monitor goes into sleep mode (as is configured in xserver).

(In reply to comment #50)
> (In reply to comment #47)
> > Please can someone else test whether the patch will help in your case?
> I have apply your patch and have not observe more crash for 8 days. But I have
> been seen twice long appearing for lock dialog, up to 90 seconds.
> 
> I think that reason is into the patch "Attempt to work around issue described
> in Bug 1288":
> while ((backingPixmap.isNull()) && (mEnsureScreenHiddenTimer->isActive())) {
> -                kapp->processEvents();
> +               
> kapp->eventLoop()->processEvents(TQEventLoop::ExcludeUserInput);
> +
> +                // HACK
> +                // Work around an issue with the underlying system whereby the
> TQTimer sometimes fails to time out!
> +                // This issue was reported in Bug #1288
> +                usleep(100);
> +                exitTimer++;
> +                if (exitTimer > (DESKTOP_WALLPAPER_OBTAIN_TIMEOUT_MS*10)) {
> +                    break;
> +                }
>              }
> Prospective time for the cycle terminate is 3s but in real usleep() do not hold
> too short time and will hold minimum 500us. Next, all other function consume
> not zero time also.

This code has been completely removed in GIT hash 2e6d8f1.  The wallpaper problem, if it recurs, should be addressed at its source in KRootPixmap, not in a delay function like that one.

Slavek, this might resolve the sleep issue you noticed.  Please let me know if you see any improvement!

Closing, as the issues reported have not reappeared when running from GIT head for the past few weeks.  If this changes, please reopen this bug report!