| Summary: | kdesktop lock fails to hide screen under memory pressure | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Timothy Pearson <kb9vqf> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | trivial | CC: | albator78, bugwatch, darrella |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | Attempt to fix missing black background in kdesktop_lock | ||
|
Description
Timothy Pearson
2011-12-18 21:24:17 CST
This should be resolved by the patch listed in bug 669. Marking as duplicate. *** This bug has been marked as a duplicate of bug 669 *** Created attachment 237 [details]
Attempt to fix missing black background in kdesktop_lock
Hello, at work I'm still using 3.5.12, I know it is now obsolete but I cannot migrate to 3.5.13 now. Still, the following issue occurs: Screensaver is set to "blank screen, start automatically after 1 minute". When screen gets locked, some times (about 1 over 100 tries), the background does not become black. The screen is actually locked (I have to enter password to unlock), BUT I can see background and applications running behind the password prompt. When it occurs, running 'ps' from a remote computer shows that the process "/opt/trinity/bin/kblankscrn.kss -root" is not running. I do not know if it is launched at all, or if it launched then dies immediatly. Parsing the code, I've found that in file 'kdesktop/lock/lockprocess.cc', there is no fallback "black background" when "mHackProc.start()" fails. The attached patch is an attempt to fix this. This appears to occur sporadically on 3.5.13 as well, and unfortunately it does not only happen under memory pressure. The random nature of this bug will make testing patches difficult. |