Tried to reproduce this in Xnest/Xvnc on fatou with 

  /usr/bin/dbus-launch  --sh-syntax --exit-with-session startkde

But I can't. How can I help here?

I can reproduce it if I just ssh to fatou and start
# dbus-launch --sh-syntax --exit-with-session bash
(starts a bash under the dbus-launch process)
then I can see (or rather not see) lost characters as I type

since I can now test it from remote ...


/work/built/mbuild/oldboy-dmueller-35098/x86_64/dbus-1-x11-1.1.4-9.x86_64.rpm

this fixes the problem for me from remote, will try again with startkde
as I get to the office.

I believe the hanging keyboard is a different issue, at least I hope so. please try oldboy-dmueller-35101

I don't know how exactly to reproduce it either, but it seems to happen when also ssh-askpass-x11 is involved. ro's login script started dbus-launch and then started ssh agent, asking for password. after that, all ewly started apps were hanging in an blocking read() called from deeply under XOpenDisplay from the X server. 

I've tried to reproduce it on my machine but I can't, but I only run on one cpu. 

ro, can you paste the exact sequence of commands that invoked ssh-password query and then startkde? perhaps I was overlooking something

in .xinitrc:
---------------------------------------------------------------------------
WINDOWMANAGER="$dbuslaunch --sh-syntax --exit-with-session $WINDOWMANAGER"
SSH_AG="ssh-agent"
exec $SSH_AG ~/bin/ssh_agent_script
---------------------------------------------------------------------------

bin/ssh_agent_script:
---------------------------------------------------------------------------
#!/bin/bash

~/bin/sshaskwhile
exec $WINDOWMANAGER
---------------------------------------------------------------------------

bin/sshaskwhile
---------------------------------------------------------------------------
#!/bin/bash

until ssh-add -l | grep $USER@ > /dev/null; do
    ssh-add .ssh/identity .ssh/id_rsa < /dev/null
done
---------------------------------------------------------------------------

oops: and no, 35101 does not help either :(

Dirk, can you reproduce this now with the instructions Rudi provided?

you can remove the ssh stuff from any test setup.

reproduced it here on my laptop MacBookPro with a Core2Duo CPU


let .xinitrc end as follows:
......................................................................
# add dbus-launch if found
dbuslaunch="`which dbus-launch 2>/dev/null`"
if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ]; then
    WINDOWMANAGER="$dbuslaunch --sh-syntax --exit-with-session $WINDOWMANAGER"
fi

#
exec $WINDOWMANAGER

# call failsafe
exit 0
.......................................................................

and that's enough to reproduce the hang.

I can't reproduce this issue on shannon (x86_64), also running STABLE. Dirk, if you can reproduce it, please reopen.

I can not reproduce it on my machine (single processor). it is reproduceable on multicore though. 

btw the bugreport was opened because imho the autostart-dbus stuf fin the global xinitrc should be removed

So you want to remove this completely from /etc/X11/xinit/xinitrc.common?

#
# Launch dbus if no session is activ or if the session is not reachable
#
if dbuslaunch="$(type -p dbus-launch)" && dbussend="$(type -p dbus-send)" ; then
    dbustest () {
        $dbussend --session --type=method_call          \
                  --dest='org.freedesktop.DBus'         \
                  /org/freedesktop/DBus                 \
                  org.freedesktop.DBus.NameHasOwner     \
                  string:'org.freedesktop.DBus'         > /dev/null 2>&1
    }
    if test -z "$DBUS_SESSION_BUS_ADDRESS" || ! dbustest ; then
        WINDOWMANAGER="$dbuslaunch --sh-syntax --exit-with-session \
                       $WINDOWMANAGER"
    fi
fi
unset dbuslaunch dbussend dbustest

IIRC it has been introduced by intention. So why now remove it again?

because I don't think it serves any purpose. it also seems that xcb_connect is apparently racy and likes to deadlock if dbus-launch is involved. Fixing the latter is much preferable of course, but removing the code that triggers it is fine with me. 

Ok. I talked with Dirk, and what he remembered was, that starting the windowmanger via dbus was still required at the time the code was introduced.
So I'll simply remove the code now. :-)

done.