Bug 1060810

Just to add: immediately after an zypper dup it worked, then I added a plaindir repository and since then I have the reported behaviour. disabling the plaindir repository did not make a difference.

This short working was the first time the Software Manager worked for many month as it always crashed. I did not check the logs then. Maybe always for the same reason but qt become more robust meanwhile to detect the error ?!

I do some software developing with C++ on Linux in case you want me to debug some stuff.

Fabian,

thanks for your bug report. I just checked; we have a very limited amount of low-level Qt painting in the YQPackageSelector widget. A recursive repaint in that code is something I haven't heard of yet; but it is entirely possible that Qt always had some flag internally that would detect such a situation and then break out of the endless recursion, and they might have added this warning recently.

A backtrace of that situation would be very helpful. If you can reproduce that problem and it hangs, you might be able to attach a debugger to that process and produce a backtrace:

    xhost +
    su -
    export DISPLAY :0
    yast2 sw_single &

wait until it hangs, then find out the PID of that process:

    ps -ef | grep y2start

then attach the debugger to that process:

    gdb /usr/bin/ruby 4711     (use the PID from above, of course)

then find out which treads exist:

    info threads

  Id   Target Id         Frame 
* 1    Thread 0x7f0fa5c15740 (LWP 29987) "y2start" 0x00007f0fa52cdcc8 in read () from /lib64/libc.so.6
  2    Thread 0x7f0fa5c5b700 (LWP 29988) "ruby-timer-thr" 0x00007f0fa52d212b in poll () from /lib64/libc.so.6
  3    Thread 0x7f0f9a8e7700 (LWP 29989) "y2start" 0x00007f0fa52d212b in poll () from /lib64/libc.so.6
  4    Thread 0x7f0f90195700 (LWP 29990) "QXcbEventReader" 0x00007f0fa52d212b in poll () from /lib64/libc.so.6
  5    Thread 0x7f0f861b6700 (LWP 29991) "QDBusConnection" 0x00007f0fa52d212b in poll () from /lib64/libc.so.6


the relevant one (the Qt thread) is the one with QXcbEventReader, so let's get a backtrace from that thread:

    thread apply 4 backtrace

Please paste that output here.

But since we don't seem to have received any similar bug report, I guess the underlying problem is some slight incompatibility or dependency problem between the Qt5 libs on your system (and maybe the YaST2 Qt UI), so it might be a good idea to force-update all of them to the latest version and make sure to uninstall any older versions.

The only reasonable explanation I could offer for this would be if you have package locks (set packages to "taboo" or "protected") which require certain older versions of any Qt5 libs. You can check this with

    sudo zypper locks

or, more verbose:

    sudo zypper locks -s

You could try updating all your Qt5 packages to the latest version:

    sudo zypper up --dry-run "*qt5*"

If you spot any weird message in that output, that might be the problem.
Omit the "--dry-run" to actually run the update.

Alternatively, you can also use the ncurses (text based) version to do the update and to spot any problem: Just make sure that $DISPLAY is not set in the shell:

    su -
    unset DISPLAY
    yast2 sw_single

First: I cannot exactly do what you request, but running it from console works!! Hence this is a very good workaround.

>xhost +
access control disabled, clients can connect from any host

>su-

>export DISPLAY :0
-bash: export: `:0': not a valid identifier

>yast2 sw_single &
And it works!

Indeed yast2 works when called from gnome-terminal or konsole but not when called via KDE Application Menue -> Settings -> YaST

Anyway, just for the records I add what you asked for (calling Yast from Application Menue)

> info threads
  Id   Target Id         Frame 
* 1    Thread 0x7f142434b740 (LWP 15930) "y2start" 0x00007f1423a245f8 in read () from /lib64/libc.so.6
  2    Thread 0x7f14243b8700 (LWP 15931) "ruby-timer-thr" 0x00007f1423a28a7b in poll () from /lib64/libc.so.6
  3    Thread 0x7f141ae77700 (LWP 15932) "y2start" 0x00007f1423a245f8 in read () from /lib64/libc.so.6
  4    Thread 0x7f140fe09700 (LWP 15933) "QXcbEventReader" 0x00007f1423a28a7b in poll () from /lib64/libc.so.6
  5    Thread 0x7f1402662700 (LWP 15934) "QDBusConnection" 0x00007f1423a28a7b in poll () from /lib64/libc.so.6
  6    Thread 0x7f13e8f2c700 (LWP 15936) "disk_cache:0" 0x00007f142372a83d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0


> thread apply 4 backtrace

Thread 4 (Thread 0x7f140fe09700 (LWP 15933)):
#0  0x00007f1423a28a7b in poll () from /lib64/libc.so.6
#1  0x00007f141d7d2387 in ?? () from /usr/lib64/libxcb.so.1
#2  0x00007f141d7d417a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007f141889b4b9 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007f141daa0d2e in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007f1423724558 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f1423a331bf in clone () from /lib64/libc.so.6
(gdb) q

OK, that backtrace actually looks good - the Qt UI is waiting for user events (mouse clicks etc).

Not sure why you can't start it from the KDE menu, though; it should simply use the appropriate .desktop file and execute the command there.

This should be /usr/share/applications/YaST2/sw_single.desktop .
Can you try to execute the command there? For me, this is

    xdg-su -c "/sbin/yast2 sw_single"

If this fails, please check if "xdg-su" works in general:

    xdg-su -c ls

This should prompt for the root password and then simply execute a "ls" in the shell you started it from.

> cat /usr/share/applications/YaST2/sw_single.desktop
[Desktop Entry]
Type=Application
Categories=Settings;System;Qt;X-SuSE-YaST;X-SuSE-YaST-Software;

X-KDE-ModuleType=Library
X-KDE-HasReadOnlyMode=true
X-SuSE-YaST-Call=sw_single

X-SuSE-YaST-Group=Software
X-SuSE-YaST-Argument=
X-SuSE-YaST-RootOnly=true
X-SuSE-YaST-AutoInst=
X-SuSE-YaST-Geometry=
X-SuSE-YaST-SortKey=20
X-SuSE-YaST-AutoInstResource=

Icon=yast-sw_single
Exec=xdg-su -c "/sbin/yast2 sw_single"

Name=Software Management
GenericName=Install or remove software packages and manage software repositories
StartupNotify=true

> xdg-su -c "/sbin/yast2 sw_single"
results in the dead window. Clicking and typing does not help, it needs to be killed.

> xdg-su -c ls
opens a dialog the root-PW prompt and when entered closes. There is no ls output I can see anywhere.

BTW:
> sudo zypper locks -s
[sudo] password for root: 
Loading repository data...
Reading installed packages...

# | Name     | Matches | Type    | Repository
--+----------+---------+---------+-----------
1 | openSUSE | 5       | product | (any)     
    Keep installed : product:openSUSE-20170522-0.x86_64 (@System)
    Do not install : [4]
        product:openSUSE-20171001-0.x86_64 (openSUSE-Tumbleweed-Oss)
        product:openSUSE-20171001-0.x86_64 (openSUSE:Tumbleweed)
        product:openSUSE-20171001-0.i586 (openSUSE-Tumbleweed-Oss)
        product:openSUSE-20171001-0.i586 (openSUSE:Tumbleweed)

> > xdg-su -c ls
>
> opens a dialog the root-PW prompt and when entered closes. There is no 
> ls output I can see anywhere.

OK, then I strongly suspect that it's the xdg-su command that doesn't work properly on your system.

I wonder why you ever get a dead window with this; AFAICS it should simply do nothing when you try to start "yast2 sw_single" that way, just like that "ls" command that did not show you any output.

-> Reassigning to the maintainer of the xdg-utils package that constains this xdg-su command.


Simon, any idea how to track this down?

It works nicely on my system which is also on Tumbleweed. No idea what's different on Fabian's system.


BTW this "recursive repaint" does not seem to be the underlying problem; AFAICS this is an unrelated warning (which deserves to be fixed as well, of course, but that's another matter).

(In reply to Stefan Hundhammer from comment #9)
> > > xdg-su -c ls
> >
> > opens a dialog the root-PW prompt and when entered closes. There is no 
> > ls output I can see anywhere.
> 
> OK, then I strongly suspect that it's the xdg-su command that doesn't work
> properly on your system.
> 
> I wonder why you ever get a dead window with this; AFAICS it should simply
> do nothing when you try to start "yast2 sw_single" that way, just like that
> "ls" command that did not show you any output.
> 
> -> Reassigning to the maintainer of the xdg-utils package that constains
> this xdg-su command.
> 
> 
> Simon, any idea how to track this down?
> 
> It works nicely on my system which is also on Tumbleweed. No idea what's
> different on Fabian's system.
> 
> 
> BTW this "recursive repaint" does not seem to be the underlying problem;
> AFAICS this is an unrelated warning (which deserves to be fixed as well, of
> course, but that's another matter).

xdg-su's behavior is different on each desktop, can you tell me your desktop and if possible if you are running under wayland?

I suspect this is related to some of the settings that Qt applies when it detects a Plasma desktop. Try:

XDG_CURRENT_DESKTOP=DOESNOTMATTER KDE_SESSION_VERSION=0 xdg-su -c "yast2 sw_single"

> XDG_CURRENT_DESKTOP=DOESNOTMATTER KDE_SESSION_VERSION=0 xdg-su -c "yast2 sw_single"
works. I run KDE, latest TW. How can I find out if I run with wayland?

(In reply to Fabian Wein from comment #12)
> > XDG_CURRENT_DESKTOP=DOESNOTMATTER KDE_SESSION_VERSION=0 xdg-su -c "yast2 sw_single"
> works. I run KDE, latest TW. How can I find out if I run with wayland?

If your running KDE I don't think you'll be running wayland unless you explicitly set it up but check for wayland in the following (presuming your user id is 1000)

systemctl status user-1000.slice

> systemctl status user-1000.slice | grep ayla  
           | |-28607 grep --color=auto ayla

Obviously not wayland. Shall I simply clean some config files?!

(In reply to Fabian Wein from comment #12)
> > XDG_CURRENT_DESKTOP=DOESNOTMATTER KDE_SESSION_VERSION=0 xdg-su -c "yast2 sw_single"
> works. I run KDE, latest TW. How can I find out if I run with wayland?

Next try:

QT_STYLE_OVERRIDE=Breeze XDG_CURRENT_DESKTOP=DOESNOTMATTER KDE_SESSION_VERSION=0 xdg-su -c "yast2 sw_single"

This reproduces the problem. Blank window I need to kill

(In reply to Fabian Wein from comment #16)
> This reproduces the problem. Blank window I need to kill

Ok, so somehow the breeze style interferes there. I cannot reproduce the issue and I don't know what could cause this behaviour. Please post your full list of repositories (with url and priorities, so preferably zypper lr -d) and locks (zypper ll).

I just noticed that with a two year old TW install, it's definitely possible that yast2-qt-branding-openSUSE is still installed. Can you remove that and try again?

(In reply to Fabian Vogt from comment #18)
> I just noticed that with a two year old TW install, it's definitely possible
> that yast2-qt-branding-openSUSE is still installed. Can you remove that and
> try again?

Thanks! Now it works perfectly!

Due to comment #19, I will close it as fixed.