D29808: KSysGuard Network Plugin: Don't use std::regex to parse the network files.

[Jiří Paleček]

jpalecek added a comment.


  In D29808#673157 , @sandsmark 
wrote:
  
  > > It's all C code whereas the rest of the helper is C++. It also relies 
very heavily on magic numbers now.
  >
  >
  >
  > > I think a much simpler implementation would be to split each line on " ", 
select the fields we want and clean them up.
  >
  > I assume this is for performance reasons, but a tiny microbenchmark showing 
that it is actually faster would be nice.
  
  
  Hi! Just out of curiosity (I'm not the OP), I created a microbenchmark here: 
https://github.com/jpalecek/ksysguard-network-microbenchmark. As a fun project, 
I added a Boost.Sphinx implementation, which was remarkably easy. Not the most 
readable code ever, beware. Some bugs were found while doing this (in both old 
and new implementation), see the code.

INLINE COMMENTS

> sandsmark wrote in ConnectionMapping.cpp:167
> instead of 87 + 1, maybe have a `constexpr int lineLength = strlen("0: 
> 0100:0277 : 
> 0A : 00:  00 16741");` above with 
> the comment?
> or:
> 
>   constexpr const char *exampleLine = "0: 
> 0100:0277 : 
> 0A : 00:  00 16741";
>   constexpr int lineLength = strlen(exampleLine);
> 
> both more understandable and less prone to accidentally putting in the wrong 
> number.
> 
> same with all other magic string offset numbers here.

Actually I don't agree with that view. I don't think `lineLength = strlen("0: 
000...`)` is readable and less error prone than `87`, only 
longer by ~100 characters and a nightmare to check. With numbers, I can check 
with an editor that shows column numbers and simple arithmetic, but comparing 
such long strings made of spaces is hard.

If you want more robustness, I would suggest using the fact that the number 
columns are aligned with the header and using something like `inode_col = 
header.find("inode")`. Or counting the fields. That would also take care of the 
possibility that the columns may not be same width across architectures (?)

REPOSITORY
  R106 KSysguard

REVISION DETAIL
  https://phabricator.kde.org/D29808

To: dkorth, ahiemstra
Cc: sandsmark, ahiemstra, jpalecek, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, 
ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D29780: Detach sensor shell agent from terminal

[Jiří Paleček]

jpalecek created this revision.
jpalecek added reviewers: Plasma, davidedmundson.
Herald added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  When I run ksysgruard from a terminal, I found out it doesn't
  connect to remote hosts' sensors (tried with localhost, but anyway)
  and messes up the terminal (which doesn't show the input
  afterwards). This is caused by ssh, which ksysguard uses to connect to
  remote host, asking for the password on the terminal. This is super
  annoying, because you don't normally expect a GUI application like
  ksysguard to ask for anything on the terminal, and also because the
  mess up later.
  
  The reason is that nothing changes the controlling terminal when
   ksysguard runs ssh, so it inherits the parent's terminal. SSH
   normally uses the terminal to get password if it has one. However, it
   will use `SSH_ASKPASS` if it doesn't, which is what we want.
  
  This patch fixes it by running whatever is ran by SensorShellAgent
   with `setsid`, which is an executable from the util-linux package. I've
   considered the following alternatives and found this one to be the
  simplest:
  
  1. Use `QProcess::startDetached`. Detaches from the terminal, but has the 
drawback that this method doesn't allow to interact with input/output or wait 
for completion, which is what we want.
  2. Use `KPtyProcess`: Not possible since while this detaches the ssh process 
from the parent's terminal, it creates a new one which would cause ssh to ask 
for password on that terminal. We would have to add code to relay interaction 
on the terminal to the user.
  3. Create our own wrapper executable. That would have the advantage that it 
works on other systems than linux, eg. freebsd.

TEST PLAN
  1. Run ksysguard from konsole
  2. Inspect sensors on another host that you need a password to log on
  3. The prompt for a password should show up as a X dialog.

REPOSITORY
  R111 KSysguard Library

BRANCH
  Plasma/5.18

REVISION DETAIL
  https://phabricator.kde.org/D29780

AFFECTED FILES
  ksgrd/SensorShellAgent.cpp

To: jpalecek, #plasma, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29616: Fix memory errors caused by using dangling pointers to SensorClients in SensorAgent

[Jiří Paleček]

jpalecek updated this revision to Diff 82568.
jpalecek added a comment.


  Move the client deregistering code from SensorBrowserModel to HostInfo
  
  Also remove the clear function. After investigating further, I've
  found out it suffers from the same problem, that it doesn't deregister
  from the hosts it removes. On top of that, it leaves dangling pointers
  in mSensorInfoMap. It doesn't really clear all the other internal
  structures. And it is never used. So I think it's best to delete it.

REPOSITORY
  R106 KSysguard

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29616?vs=82486=82568

REVISION DETAIL
  https://phabricator.kde.org/D29616

AFFECTED FILES
  gui/SensorBrowser.cpp
  gui/SensorBrowser.h
  gui/ksysguard.cpp
  gui/ksysguard.h

To: jpalecek, davidedmundson, ahiemstra
Cc: anthonyfieroni, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29616: Fix memory errors caused by using dangling pointers to SensorClients in SensorAgent

[Jiří Paleček]

jpalecek added inline comments.

INLINE COMMENTS

> ahiemstra wrote in SensorBrowser.cpp:53
> I agree with Anthony though, if you delete a hostInfo it _should_ remove its 
> connection. So it's better to move this code into a destructor for HostInfo.

But the host info, at least in its present form, doesn't have the client 
pointer to pass to `disconnectClient`. But I can see your point, I will change 
it.

REPOSITORY
  R106 KSysguard

REVISION DETAIL
  https://phabricator.kde.org/D29616

To: jpalecek, davidedmundson, ahiemstra
Cc: anthonyfieroni, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29616: Fix memory errors caused by using dangling pointers to SensorClients in SensorAgent

[Jiří Paleček]

jpalecek added inline comments.

INLINE COMMENTS

> anthonyfieroni wrote in SensorBrowser.cpp:53
> When you delete the map content, all agents should loose their connections, 
> no?

No, it only deletes the HostInfo structure. See the source 
.
 It doesn't disconnect anything. Nor does deleting `this`, as the Agent holds 
the client as a bare pointer, it can't know that it ceased to exist. It isn't 
even a `QPointer` (probably bc. `SensorClient` isn't a `QObject`).

REPOSITORY
  R106 KSysguard

REVISION DETAIL
  https://phabricator.kde.org/D29616

To: jpalecek, davidedmundson, ahiemstra
Cc: anthonyfieroni, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29618: Fix case fallback warning

[Jiří Paleček]

jpalecek created this revision.
jpalecek added reviewers: Plasma, davidedmundson.
Herald added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  Courtesy of gcc warnings: in decoding of the "ps" reply, the answer
   would be wrongly used as free memory as well due to a missing break.

REPOSITORY
  R111 KSysguard Library

REVISION DETAIL
  https://phabricator.kde.org/D29618

AFFECTED FILES
  processcore/processes_remote_p.cpp

To: jpalecek, #plasma, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29617: Renice all threads of a multithreaded process

[Jiří Paleček]

jpalecek created this revision.
jpalecek added reviewers: Plasma, davidedmundson.
Herald added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  This is a mirror of D29615  implemented 
in libksysguard for local
   processes. All the same comments apply.

REPOSITORY
  R111 KSysguard Library

BRANCH
  Plasma/5.18

REVISION DETAIL
  https://phabricator.kde.org/D29617

AFFECTED FILES
  processcore/processes_linux_p.cpp

To: jpalecek, #plasma, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29616: Fix memory errors caused by using dangling pointers to SensorClients in SensorAgent

[Jiří Paleček]

jpalecek created this revision.
jpalecek added reviewers: davidedmundson, ahiemstra.
Herald added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  When some SensorClients are destroyed, eg. when KSysguard is closed,
   they fail to deregister themselves from SensorAgent. This may cause a
   crash when further messages arrive for them. This patch fixes that.
  
  BUG: 350140

REPOSITORY
  R106 KSysguard

REVISION DETAIL
  https://phabricator.kde.org/D29616

AFFECTED FILES
  gui/SensorBrowser.cpp
  gui/ksysguard.cpp
  gui/ksysguard.h

To: jpalecek, davidedmundson, ahiemstra
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29615: Nice all threads of multithreaded programs

[Jiří Paleček]

jpalecek created this revision.
jpalecek added reviewers: ahiemstra, davidedmundson.
Herald added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  Setting process priorities by ksysguard has the flaw that it only
   sets priority of a single thread of a multithreaded program. For
   example, if I want to put handbrake encoding to the background, it
   usually fails as other threads from the same process continue to hog
   the CPU. This patch changes the behavior by attempting to change the
   priority of all threads (on Linux).
  
  There is a caveat: when the threads' priorities were previously
   different, it may mean you change the priority against the logic of
   the application. For example some background threads of an
   application might end up having the same priority as the
   foreground. As a corollary, the call may mean lowering priority of
   some threads, but raising it for others and thus fail due to
   insufficient capabilities. Still, I think this behavior is actually
   the only one usable, until we have individual threads in
   ksysguard. Even then, I doubt people will look at the individual
   threads when renicing. Till then, the ability to renice a task is a
   need which ksysguard should fulfill, but unfortunately doesn't.
  
  Note: this only changes the behavir for remote computers. Local use
   needs a similar fix in libksysguard.

TEST PLAN
Run a multithreaded process which uses the CPU (like video coding)
Set its priority to low
Check with ps -p $pid -L o pid,lwp,pri,comm

REPOSITORY
  R106 KSysguard

BRANCH
  Plasma/5.18

REVISION DETAIL
  https://phabricator.kde.org/D29615

AFFECTED FILES
  ksysguardd/Linux/ProcessList.c

To: jpalecek, ahiemstra, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D23592: ksysguard: handle multiple mounts to the same mountpoint gracefully

[Jiří Paleček]

jpalecek added a comment.


  Could this be committed please?

REPOSITORY
  R106 KSysguard

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23592

To: jpalecek, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D23704: Allow tmpfs in ksysguard disk space monitor

[Jiří Paleček]

jpalecek added a comment.


  @davidedmundson Can you please have a look at this?

REPOSITORY
  R106 KSysguard

REVISION DETAIL
  https://phabricator.kde.org/D23704

To: jpalecek, #plasma, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D23704: Allow tmpfs in ksysguard disk space monitor

[Jiří Paleček]

jpalecek created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
jpalecek requested review of this revision.

REVISION SUMMARY
  As tmpfs mounts are more widely used for shared memory in browsers like 
Chromium and Firefox, there is a need for more and more space in such 
filesystems, with grave circumstances when the space is exhausted - it causes 
instability, crashes or black display in both of these browsers. Given this 
importance, I suggest tmpfs should not be blacklisted from disk space reporting 
in ksysguardd. Because tmpfs "devices" don't start with a /, it is needed to 
obviate the test for "real" device names as well.

TEST PLAN
  Open ksysguard
   Check that sensor Disk Space/dev/shm/... is there
   Check that it shows partly full when you have firefox running

REPOSITORY
  R106 KSysguard

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23704

AFFECTED FILES
  ksysguardd/Linux/diskstat.c

To: jpalecek
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23595: Speed up sending request to ksysguardd

[Jiří Paleček]

jpalecek created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
jpalecek requested review of this revision.

REVISION SUMMARY
  While investigating bug 407526, I discovered that most of the time is spent 
in SensorAgent::sendRequest. This is because it searches the whole queue 
lineraly, which could take a lot of time if there's a lot of requests. This 
patch speeds it up by using a `QSet` of outstanding requests, obviating the 
need to search the queues.
  
  Part of T11473: #407526: plasma + ksysguardd causing high cpu load 


REPOSITORY
  R111 KSysguard Library

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23595

AFFECTED FILES
  ksgrd/SensorAgent.cpp
  ksgrd/SensorAgent.h

To: jpalecek
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23594: Use sensor index for request ID in SystemMonitorEngine::updateSensors()

[Jiří Paleček]

jpalecek created this revision.
jpalecek added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  When id is -1, the answerReceived function expects the response to be the 
list of sensors. However, this function sends commands to update values of 
individual sensors. These should have a positive id in the answerReceived 
function.
  
  However, I may be wrong there. I couldn't find a place that actually calls 
that function, so I couldn't verify the functionality. But IMHO it should be 
akin to updateSourceEvent, which this patch does.

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23594

AFFECTED FILES
  dataengines/systemmonitor/systemmonitor.cpp

To: jpalecek
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23593: Don't accept duplicated sensor names from ksysguardd

[Jiří Paleček]

jpalecek created this revision.
jpalecek added a reviewer: davidedmundson.
jpalecek added a project: Plasma.
jpalecek requested review of this revision.

REVISION SUMMARY
  It shouldn't happen, but sometimes ksysguardd sends the same sensor name 
twice or more times. That would result in excessive cpu load requesting the 
data from ksysguard multiple times. This is a quick fix for that behaviour, 
just by ignoring the duplicated sensors.
  
  Part of T11473: #407526: plasma + ksysguardd causing high cpu load 
.

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23593

AFFECTED FILES
  dataengines/systemmonitor/systemmonitor.cpp

To: jpalecek, davidedmundson
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23592: ksysguard: handle multiple mounts to the same mountpoint gracefully

[Jiří Paleček]

jpalecek created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
jpalecek requested review of this revision.

REVISION SUMMARY
  On Linux, it may happen that two mounts are mounted to the same mount point. 
Two different devices or the same device twice, doesn't matter. As it currently 
is, ksysguardd handles this case badly. When updating sensors, the 
checkDiskStat fuction searches the previously known mounts for the items from 
the current list, by comparing the mount points only. If found, the item from 
the old list is deleted and the new item is deemed to be preexisting.
  
  However, if there are two items with the same mountpoint, both get deleted on 
the first occurence of the mountpoint in the list. Therefore, the second one 
doesn't have any corresponding "old" entry, and is deemed to be newly existing. 
This means that ksysguardd signals to its client that there are new sensors, 
and, atop of that, registers the "new" monitors. This eventually leads to the 
list of monitors expanding to tens of thousands of items. This can cause quite 
a cpu load eg. in Plasma.
  
  This patch changes the logic so that every mount will only delete one 
corresponding item from the old list. Thus, the bloat of the list of sensors, 
at least in case of disk sensors, is prevented.
  
  Part of T11473: #407526: plasma + ksysguardd causing high cpu load 
.

REPOSITORY
  R106 KSysguard

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23592

AFFECTED FILES
  ksysguardd/Linux/diskstat.c

To: jpalecek
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek added a comment.


  In D8673#245716 , @davidedmundson 
wrote:
  
  > Thanks, do you have commit access?
  
  
  Sorry, no.

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8673

To: jpalecek, #plasma, davidedmundson
Cc: broulik, graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek updated this revision to Diff 32067.
jpalecek added a comment.


  I finally got round to this. So:
  
  - this revision stores the socketpair fds in KSMServer instance, so they can 
be closed later.
  
  - also, it uses the modern QObject::connect syntax with pmfs instead of 
strings
  
  - the patch is refreshed so it applies on current master

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8673?vs=21942=32067

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8673

AFFECTED FILES
  ksmserver/server.cpp
  ksmserver/server.h

To: jpalecek, #plasma
Cc: broulik, graesslin, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek added a comment.


  In https://phabricator.kde.org/D8673#164830, @davidedmundson wrote:
  
  > Do the sockets need closing in the destructor?
  
  
  Good point. I assumed the `KSMServer` instance is practically a singleton 
(being assigned to global `the_server` etc.) which is created only once during 
running of the process. In that case, the sockets would be destroyed anyway so 
I kind of cut that corner and left it be. It would certainly be cleaner to 
close them in the destructor.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D8673

To: jpalecek, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek edited the summary of this revision.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D8673

To: jpalecek, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek edited the summary of this revision.
jpalecek added a reviewer: Plasma.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D8673

To: jpalecek, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D8673: Sanitize signal handling in ksmserver

[Jiří Paleček]

jpalecek created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  The TERM signal handling in ksmserver invokes functions which
  are not async-signal safe, like Qt functions and C++
  destructors. Moreover, the signal handling can occur in other than the
  main thread, which leads to Qt complaining about functions being
  invoked from the wrong thread. Such a crash can be seen in a report of
  "https://bugs.kde.org/show_bug.cgi?id=384316; 
.
  
  To fix both of these issues, this change makes the signal handling use
  the self-pipe trick, which signals the need for termination to the
  main thread by writing to a special-purpose file descriptor. The main
  loop then takes care of the termination. This is mostly inspired by 
http://doc.qt.io/qt-5/unix-signals.html.
  
  Note that `QApplication::quit` already does what we need when destroying
  the server, particularly deleting `the_server`/calling `cleanUp()`.
  
  BTW I noticed the code (here and in XIO error handler) makes quite
  sure the_server is zeroed. However, other code in ksmserver is not so
  keen on checking `the_server` is !0 when using it.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  Plasma/5.10

REVISION DETAIL
  https://phabricator.kde.org/D8673

AFFECTED FILES
  ksmserver/server.cpp

To: jpalecek
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart