From kde-bugs-dist  Wed Jan 24 08:24:20 2001
From: John Califf <jcaliff () compuzone ! net>
Date: Wed, 24 Jan 2001 08:24:20 +0000
To: kde-bugs-dist
Subject: Bug#19005: dcop runs amok
X-MARC-Message: https://marc.info/?l=kde-bugs-dist&m=98032535916824

Package: kdelibs/dcop
Version: cvs - week of Jan 20, 2000 pre 2.1

There are consistent and recurring problems with dcop, ksycoca, kded and
klauncher when running *any* kde app from the command line (like from an
xterm or rxvt) in a window manager other than kwin, or when startkde has
not been gimmicked to run, sort of, with another wm.  These problems
will even occur in kwin when using a terminal other than konsole as a
login term.

First, the non-critical part.  Dcop sends unnecessary and very
irritating output to the command line as a result of any kde app being
run or being closed in this situation.  Sure, I know how to redirect
output, but joe user does not.  The same goes for the other 3 members of
these four horsemen of the apocalypse - kded, rebuildksycoca and
klauncher.  

The critical part, potentially resulting in data corruption or even loss
of one's entire system, is that when the last kde app is closed, dcop
and/or klauncher exit with ugly error messages (signal 11, signal 15,
etc.) and these messages occur some time after the kde app close.  These
messages can and do insert unpredicatable text into a user's command
sequence, so that if you close a kde app and are entering a command ten
or so seconds later, text from these messages gets inserted.  If you hit
return then the arbitrary command is executed.  It has happend to me
several times.  Fortunately the commands were nonsensical and returned
an error - command not found.

It's only common courtesy for all these debugging or output messages to
be redirected to a file by default, and I feel very strongly that this
should be built into kdDebug and other message outputting tools used for
debugging.  If a programmer wants to see output, then he can "tee" the
message or even better a "tee" equivalent with a switch to output
messages to stdout or not should be built into these kde debugging
tools.  The end user should *NEVER* see these messages on the command
line unless a real error has occured, and kde programmers should use
common sense and common courtesy in using cout, printf, kdDebug, qdebug
and other aids which  output messages for their own use.  All such
messages should either go to a file, or be conditional.  For example:

if(!img->save()) kdDebug() << "error saving image" << endl;

NOT: 

kdDebug() << "save image called: return code is: " << rc << endl;


In the latter case all such debugging messages should be removed or
commented out prior to a release of kde, like upcoming kde 2.1, or some
kind of conditionality should be built into the messages themselves. 
For example, with ENABLE_FINAL certian messages should generate no
output.

There are more dimensions to this problem.  Often messages from one
shell will appear on another xterm unpredictably.  Because dcop is a
separate process, it is disconnected from the apps communicating with it
and ending the application does not stop dcop from its rude
interruptions.  Only when the very last kde app started in that login
shell is closed does dcop shut down, but then we get the critical
problem mentioned above.

This is a very serious matter and was the number two complaint about Kde
2.0. Unpredictable and unnecessary messages from dcop and friends was
second only to the tendancy of kword to crash in user compaints about
kde 2 in linux forums.  As shown above, these messages are not harmless
especially when generated by dcop which has its own sense of timing
apart from what one normal expects when entering sequential commands.

John