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.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx
Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
