Bug 956

The problem is kdcop trying to communicate with tdeinit_phase1. Currently tdeinit_phase1 is only a basic C++ wrapper around kwrapper ksmserver. There is no mechanism in tdeinit_phase1 to communicate with anything.

In starttde, substituting

$TDEDIR/bin/tdeinit_phase1

with

$TDEDIR/bin/kwrapper ksmserver

resolves the problem with kdcop not starting correctly.

Currently this work-around is the only solution. A long term solution for updating tdeinit_phase1 is required.

I am attaching two stdout/stderr output logs. One is with starttde configured to use tdeinit_phase1, where kdcop never fully starts and hangs. The other log is with starttde using the old method of "ksmserver kwrapper" from which kdcop starts normally and does not hang.

The two logs are the same up to lines 207, where the stalled version ends. The problem seems to be kdcop being unable to establish keyboard shortcuts.

Created attachment 523 [details]
kdcop log output and stalling with tdeinit_phase1

Created attachment 524 [details]
kdcop log output and starting normally with 'ksmserver kwrapper'

Workaround:

In starttde:

AS IS:

# tdeinit_phase1 is still experimental.
$TDEDIR/bin/tdeinit_phase1
EXIT_CODE="$?"
# If tdeinit_phase1 should cause problems, here is the old way:
# test -n "$TDEWM" && TDEWM="--windowmanager $TDEWM"
# $TDEDIR/bin/kwrapper $TDEDIR/bin/ksmserver $TDEWM
# EXIT_CODE="$?"

CHANGE TO:

# tdeinit_phase1 is still experimental.
# $TDEDIR/bin/tdeinit_phase1
# EXIT_CODE="$?"
# If tdeinit_phase1 should cause problems, here is the old way:
test -n "$TDEWM" && TDEWM="--windowmanager $TDEWM"
$TDEDIR/bin/kwrapper $TDEDIR/bin/ksmserver $TDEWM
EXIT_CODE="$?"

(In reply to comment #1)
> The problem is kdcop trying to communicate with tdeinit_phase1. Currently
> tdeinit_phase1 is only a basic C++ wrapper around kwrapper ksmserver. There is
> no mechanism in tdeinit_phase1 to communicate with anything.
> 
> In starttde, substituting
> 
> $TDEDIR/bin/tdeinit_phase1
> 
> with
> 
> $TDEDIR/bin/kwrapper ksmserver
> 
> resolves the problem with kdcop not starting correctly.
> 
> Currently this work-around is the only solution. A long term solution for
> updating tdeinit_phase1 is required.

I suspect that disabling DCOP support in tdeinit_phase1 would solve the problem.  IIRC this is a trivial fix, requiring at most a few lines of code in main().

Tim

Okeydokey, I'll be watching for the patch.... :-)

Modifying the report to a regression for easier identification.

I can confirm the same problem in v3.5.13.1. Note that tdeinit_phase1 is not present in v3.5.13.1!

I noticed, however, dependent on what type of session is selected:
+ default (run x-session-manager) => kdcop works
+ TDE (run startkde / starttde) => kdcop does not work


I think it has to do with this code (tdm/kfrontend/kgapp.cpp):

        if (twin) {
                if (twin->isRunning()) {
                        if (login_session_wm.endsWith("/starttde") || (login_session_wm == "failsafe")) {
                                twin->closeStdin();
                                twin->detach();
                                dcop->detach();
                        }
                        else {
                                twin->kill();
                                dcop->kill();
                        }
                }
                delete twin;
                delete dcop;
        }

Because it is dependent on the name of session starter (which is actually a bug) and not know when the "x-session-manager" is actually starttde, so it behaves like a stranger => kdcop works.

Yes, tdeinit_phase1 is not in 3.5.13.x. The work-around I posted in Comment 5 should work for 3.5.13.x.

Note: The code snippet you referenced is in TDM. I don't use TDM (I start X from the command line). Yet I still experience the problem unless I use the work-around in Comment 5.

(Odpověď na komentář #10)
> Yes, tdeinit_phase1 is not in 3.5.13.x. The work-around I posted in Comment 5
> should work for 3.5.13.x.
> 
> Note: The code snippet you referenced is in TDM. I don't use TDM (I start X
> from the command line). Yet I still experience the problem unless I use the
> work-around in Comment 5.

No, Darrell, read it again - in v3.5.13.1 is code same that you mention as a work-around. So this "change" really does not help in v3.5.13.1 ;)

Okay. Tim has an idea how to fix (Comment 6). When a patch is proposed we both can test.

Tim, please don't tag the bug report resolved until both Slavek and I can test thoroughly. :-)

DCOP registration disabled for tdeinit_phase1 in GIT hash 1085164.

Please test and close the bug report if kdcop is now repaired!

(Odpověď na komentář #13)
> DCOP registration disabled for tdeinit_phase1 in GIT hash 1085164.
> 
> Please test and close the bug report if kdcop is now repaired!

Hmm, interesting. But it has one major shortcoming. The problem I have observed in 3.5.13.1, but there is no tdeinit/phase1 - kwrapper ksmserver is started directly from startkde. Is phase1 right place to fix?

I will test today.

Slavek, unless I'm missing the big picture (very possible!), as 3.5.13.1 does not contain tdeinit_phase1, seems the solution is not to backport the GIT version of starttde to 3.5.13's startkde. Just delete those lines from the 3.5.13.1 startkde. Similar to my proposed work-around, but just delete the commented lines regarding tdeinit_phase1.

Here you can see current state of startkde from v3.5.13.1:

http://git.trinitydesktop.org/cgit/tdebase/tree/startkde?h=origin/v3.5.13-sru

I do not understand, what should I blow?

On the test machine, I just test that kdcop works every time - regardless of the starting from kdm by startkde or using x-session-manager. So it was a wrong assumption.

Slavek, Okay, I see. I misunderstood. Sorry!

Tim, with a restored starttde using tdeinit_phase1, the latest patch allows kdcop to start). No xsession log weirdness either. Thank you!

I don't know what remains to help Slavek, but the patch does resolve my original report.

Tim, Darrell, thank you for giving direction. I found "my" part of the problem and repaired in identical manner as Tim in tdeinit_phase1 - fixed in GIT hash a1380ee8 (in gtk-qt-engine - so it was applied to all GTK applications).

Curious:

Should gtk-qt-engine be using dcop?

Why did this affect you and not others? (Or, are the rest of us not seeing the problem??)

gtk-qt-engine runs "hidden" KApplication. But GTK program, of course, unaware of the DCOP. Others have not noticed a problem, because not using Kdcop :)