Bug 195223 - plasma-desktop uses illegal DBUS interface name
Summary: plasma-desktop uses illegal DBUS interface name
Status: RESOLVED DUPLICATE of bug 297020
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: SVN
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-04 16:12 UTC by Will Stephenson
Modified: 2024-05-10 22:16 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Stephenson 2009-06-04 16:12:49 UTC
Version:            (using Devel)
Installed from:    Compiled sources

org.kde.plasma-desktop is illegal and qdbus complains about it:

"
Interface names

Interfaces have names with type STRING, meaning that they must be valid UTF-8. However, there are also some additional restrictions that apply to interface names specifically:

    *

      Interface names are composed of 1 or more elements separated by a period ('.') character. All elements must contain at least one character.
    *

      Each element must only contain the ASCII characters "[A-Z][a-z][0-9]_" and must not begin with a digit. 
"

from http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names
Comment 1 Aaron J. Seigo 2009-06-10 07:08:23 UTC
... and that's set by kdelibs when it registers the defaut interface. which means any application with '-' in its name, which is afaik perfectly valid otherwise, will get this (apparently harmless, btw) error.

so afaik this is not a plasma bug at all but a generic kdelibs bug. i spent a few minutes trying to hunt this down some time ago but trying to find where exactly to do a search and replace on the app name string so it registers (and later references) a legal name proved longer than the time i had and i haven't gone back to look at it since.
Comment 2 Artur Souza (MoRpHeUz) 2009-06-11 19:14:52 UTC
It's kuniqueapplication.cpp that register this in the wrong way. It just get's the name of the application and register that. As names like "plasma-desktop" are valid on the system, kuniqueapplication should filter illegal chars (maybe replace "-" by "_").

To avoid this kind of problems later, we can create a method to return the "dbusInterfaceName()" for a given application name and applications like kquitapp should use that.

Changing Product from plasma to kdelibs.
Comment 3 Harold K. Brown 2012-09-23 14:38:03 UTC
I discovered what seems to be a potential D-Bus related problem.  I have been tracking down plasma-desktop 100% CPU utilization and when I try to use nepomukcontroller I get the following when started from a console.  This thread is not a perfect match, but seemed the best place for it.

user@Owl:~$ nepomukcontroller 
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.

user@Owl:~$ nepomukcontroller -v
Qt: 4.8.2
KDE Development Platform: 4.8.4 (4.8.4)
Nepomuk Controller: 1.0

It is possible this it is a distribution problem, but I have no evidence one way or the other.  My distribution is:
Debian wheezy 
3.2.0-3-amd64
Nvidia driver package
In sync with wheezy distribution

My hardware is:
ASUS SABERTOOTH 990FX Motherboard
GeForce GTX 550 Ti
32 GBytes of RAM ECC (Kingston KVR13E9/8HM)
AMD FX(tm)-8150 Eight-Core Processor

At this point I have partially resolved the 100% CPU issue on this system.  At least when using top plasma-desktop does not seem to be a factor, where before it would seek to 100% usage and then lock the system after a day or so.  If I can reproduce the 100% CPU resolution, I will post elsewhere.
Comment 4 Christoph Feck 2012-09-23 15:03:08 UTC
Harold, what you describe is bug 297020, which (while annoying) should not cause any harm.
Comment 5 Christoph Cullmann 2024-05-10 22:16:43 UTC

*** This bug has been marked as a duplicate of bug 297020 ***