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.