Created attachment 1270780 [details]
strace log

attachment created as:
DISPLAY=:1 strace -f system-config-printer &> /tmp/s-c-printer.log

---
there is very strange behavior, when strace is WITHOUT '-f' its not reproduced!

for the first view between rhel73 and rhel74 there are more of these lines with "Operation not supported"

[pid  5129] ioctl(18, SIOCETHTOOL, 0x7fa2d37fd0a0) = -1 EOPNOTSUPP (Operation not supported)

anyway starce log is not

It won't freeze for me, all I can see is:

/usr/share/system-config-printer/system-config-printer.py:30: PyGIWarning: GdkPixbuf was imported without specifying a version first. Use gi.require_version('GdkPixbuf', '2.0') before import to ensure that the right version gets loaded.
  from gi.repository import GdkPixbuf
/usr/share/system-config-printer/system-config-printer.py:32: PyGIWarning: Gdk was imported without specifying a version first. Use gi.require_version('Gdk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gdk
/usr/share/system-config-printer/system-config-printer.py:33: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/share/system-config-printer/jobviewer.py:27: PyGIWarning: Notify was imported without specifying a version first. Use gi.require_version('Notify', '0.7') before import to ensure that the right version gets loaded.
  from gi.repository import Notify
/usr/share/system-config-printer/jobviewer.py:54: PyGIWarning: GnomeKeyring was imported without specifying a version first. Use gi.require_version('GnomeKeyring', '1.0') before import to ensure that the right version gets loaded.
  from gi.repository import GnomeKeyring
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Caught non-fatal exception.  Traceback:
File "/usr/share/system-config-printer/probe_printer.py", line 255, in _do_find
    fn ()
File "/usr/share/system-config-printer/probe_printer.py", line 367, in _probe_hplip
    stderr=null)
File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
Continuing anyway..

What is you version of python-gobject?

Created attachment 1270932 [details]
journal-good

Journal from VM, where system-config-printer works.

Created attachment 1270934 [details]
journal-bad

Journal from 1minutetip machine, where system-config-printer hangs.

yeah both cups-pk-helper and zenity were rebased in 7.4 too

Created attachment 1271150 [details]
GDB output

Adding gdb output, which was got by attaching to running system-config-printer. It stays on futex.

I'm still not able to reproduce it locally but looking at the available machine it seems that it is a problem related to samba. If I call "thread apply all bt" in gdb attached to the process it is stuck in samba's opendir().
Looking at it again, it is not stuck anymore :(.

Btw clicking on the "Windows printer via SAMBA" and then "Browse" froze the tool too.

(In reply to Marek Kašík from comment #18)
> Looking at it again, it is not stuck anymore :(.

It freezes again.

I still can not reproduce it locally. I would recommend you to try to find minimal example which reproduces this. It should be something which calls the "_probe_smb()" in similar environment (glib's loop, etc.) and then cut all the pieces of code which don't change the resulting behaviour. After that you will hopefully have a small set of operations for which you have to check whether they are used correctly.
Good luck.

Thanks, Marek. I will try to reproduce it as you say. I will ask Andreas about Samba, if its rebase could be the source of this problem.

Andreas, do you have any ideas about this issue?

 After cooperation with Andreas I found out the component which causes this issue - libtdb. I attached two strace outputs - one when everything is ok, other when freeze happens. This issue appeared after libtdb's rebase to 1.3.12 from 1.3.8. I can see that thread, which is using libtdb, stays on rt_sigsuspend call, which probably causes start of main thread of s-c-p, which freeze on futex after that.
I tried RHEL version of s-c-p in Fedora and there worked fine. Same with python-smbc package. The fact that libtdb causes this bug, I found out when I updated this package and issue appeared.
I reassign this bugzilla to libtdb due facts mentioned earlier. Kuba, as Petr wrote in comment #24, you can reproduce the issue on that machine.

Created attachment 1274386 [details]
Strace when s-c-p freezes

Created attachment 1274387 [details]
Strace when s-c-p works ok

Created attachment 1274517 [details]
Threads backtrace of s-c-p

Jakub, I'm doing a 'git bisect' with Zdenek.

(In reply to Andreas Schneider from comment #29)
> Jakub, I'm doing a 'git bisect' with Zdenek.

Thank you very much.

This looks like:
https://bugzilla.samba.org/show_bug.cgi?id=12593

Patch tested and works, pushed to Samba master.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1948