7 Feb
2019
7 Feb
'19
6:21 p.m.
On 02/07/2019 09:52 AM, Russell Brown wrote:
As the code I posted on bugzilla used a crude fixed
buffer, here's a
cleaned up version that uses malloc.
*** /tmp/tdebase-trinity-14.0.6~pre38/kdesktop/lock/main.cc Thu Feb 7 15:48:21 2019
--- /usr/tmp/tdebase-trinity-14.0.6~pre38/kdesktop/lock/main.cc Sun May 20 19:41:55 2018
***************
*** 325,336 ****
#endif
}
! char *locknameroot="kdesktop_lock_lockfile.";
! char *lockfilename = (char*)malloc(strlen(locknameroot) +
strlen(getenv("DISPLAY")) + 1);
I haven't followed the issue too closely, but in the past, there was an issue
that would cause high CPU usage caused by a security addition to either KDM or
the lockscreen itself. I would ensure this wasn't a regression (Slavek may
recall, it was in the 2012-14 timeframe)
Regarding the proposed code, only one quandary -- where is lockfilename freed?
(if this is allocated in a forked process that later dies and releases the
memory then you are fine, but if not, it seems this would leak memory each
time lockfilename is allocated -- unless there is a free later not shown in
the code posted)
--
David C. Rankin, J.D.,P.E.