gnome-calculator takes 55 seconds to start!

In case this is related, I'm using X11 forwarding.

1:45~beta-1 has the same issue (with the additional blank window bug,
see bug 1043559).

As a blind guess, this may be related to https://bugs.debian.org/1032584

However, I don't think gnome-calculator is supposed to use portals at
all. So maybe that's completely unrelated.

Are you able to reproduce this issue with any other apps?

If you close gnome-calculator, wait a few seconds, and then restart
the app, does it also take about a minute to restart?

Thank you,
Jeremy Bícha

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018880

but there was "only" a 25-second delay.

Here, there are actually 3 timeouts: a 25-second one, a 15-second one,
and a 10-second one:

[...]
2311078 1692124867.398309 poll([{fd=6, events=POLLIN}], 1, 0) = 1 ([{fd=6, revents=POLLIN}])
2311078 1692124867.398379 read(6, "\3\0\0\0\0\0\0\0", 8) = 8
2311078 1692124867.398442 read(6, 0x7fe4edbfc780, 8) = -1 EAGAIN (Resource temporarily unavailable)
2311078 1692124867.398538 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.398608 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\v\0\0\0005\0\0\0", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 16
2311078 1692124867.398704 sendmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\256\0\0\0\f\0\0\0y\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=318}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 318
2311078 1692124867.398800 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.398868 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.398937 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\1s\0\5\0\0\0:1.86\0\0\0\5\1u\0\n\0\0\0\7\1s\0\24\0\0\0"..., iov_len=56}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) =
56
2311078 1692124867.399034 sendmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1(\0\0\0\r\0\0\0\203\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=192}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 192
2311078 1692124867.399131 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.399224 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.399294 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\f\0\0\0005\0\0\0", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 16
2311078 1692124867.399395 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.399463 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.399531 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\1s\0\5\0\0\0:1.86\0\0\0\5\1u\0\v\0\0\0\7\1s\0\24\0\0\0"..., iov_len=56}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) =
56
2311078 1692124867.399625 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.399716 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.399788 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\r\0\0\0005\0\0\0", iov_len=16}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 16
2311078 1692124867.399880 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.399948 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
2311078 1692124867.400017 recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\6\1s\0\5\0\0\0:1.86\0\0\0\5\1u\0\f\0\0\0\7\1s\0\24\0\0\0"..., iov_len=56}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) =
56
2311078 1692124867.400126 poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.400219 poll([{fd=5, events=POLLIN}], 1, 0) = 0 (Timeout)
2311078 1692124867.400289 write(6, "\1\0\0\0\0\0\0\0", 8) = 8
2311078 1692124867.400379 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = 1 ([{fd=6, revents=POLLIN}])
2311078 1692124867.400447 read(6, "\1\0\0\0\0\0\0\0", 8) = 8
2311078 1692124867.400512 read(6, 0x7fe4edbfc780, 8) = -1 EAGAIN (Resource temporarily unavailable)
2311078 1692124867.400570 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1 <unfinished ...>
2311075 1692124892.422559 <... poll resumed>) = 0 (Timeout)
[...]
2311078 1692124892.610752 read(6, "\1\0\0\0\0\0\0\0", 8) = 8
2311078 1692124892.610832 read(6, 0x7fe4edbfc780, 8) = -1 EAGAIN (Resource temporarily unavailable)
2311078 1692124892.610912 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1 <unfinished ...>
2311127 1692124893.105512 <... futex resumed>) = -1 ETIMEDOUT (Connection timed out)
2311127 1692124893.105687 futex(0x565550cbde80, FUTEX_WAIT_PRIVATE, 0, {tv_sec=14, tv_nsec=999999184}) = -1 ETIMEDOUT (Connection timed out)
2311127 1692124908.106238 rt_sigprocmask(SIG_BLOCK, ~[RT_1], NULL, 8) = 0
2311127 1692124908.106386 madvise(0x7fe481ffc000, 8368128, MADV_DONTNEED) = 0
2311127 1692124908.106489 exit(0)       = ?
2311127 1692124908.106599 +++ exited with 0 +++
2311075 1692124917.632573 <... poll resumed>) = 0 (Timeout)
[...]
2311078 1692124892.610752 read(6, "\1\0\0\0\0\0\0\0", 8) = 8
2311078 1692124892.610832 read(6, 0x7fe4edbfc780, 8) = -1 EAGAIN (Resource temporarily unavailable)
2311078 1692124892.610912 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1 <unfinished ...>
2311127 1692124893.105512 <... futex resumed>) = -1 ETIMEDOUT (Connection timed out)
2311127 1692124893.105687 futex(0x565550cbde80, FUTEX_WAIT_PRIVATE, 0, {tv_sec=14, tv_nsec=999999184}) = -1 ETIMEDOUT (Connection timed out)
2311127 1692124908.106238 rt_sigprocmask(SIG_BLOCK, ~[RT_1], NULL, 8) = 0
2311127 1692124908.106386 madvise(0x7fe481ffc000, 8368128, MADV_DONTNEED) = 0
2311127 1692124908.106489 exit(0)       = ?
2311127 1692124908.106599 +++ exited with 0 +++
2311075 1692124917.632573 <... poll resumed>) = 0 (Timeout)
[...]

An error message is also output to the terminal:

(gnome-calculator:2311075): Gtk-CRITICAL **: 20:42:05.924: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying

I've just tried baobab (which happens to be installed).
Also a 55-second delay, with the error

(baobab:2311599): Gtk-CRITICAL **: 21:27:19.847: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying

For gnome-terminal, I get only a 25-second delay (like in bug 1018880),
then a fatal error:

# Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

No issues with non-GNOME applications.

Yes, same issue.

gnome-terminal is a GTK3 app. Baobab and gnome-calculator now use GTK4
and libadwaita. A lot of GNOME apps now use GTK4 and libadwaita. Maybe
this is a general problem for GTK4 apps. If so, please reassign this
bug to src:gtk4

transmission-gtk and megapixels are some of the few GTK4 apps in
Debian that don't use libadwaita.

Thank you,
Jeremy Bícha

Control: reassign -1 src:gtk4
Control: retitle -1 GTK4 applications start with a 25- or 50-second delay when using X11 forwarding
Control: found -1 4.10.5+ds-3

In my strace output, process 2311127 (involved in the last 2 timeouts)
appears to be related to libadwaita as it reads files with "Adwaita"
in the pathnames.

transmission-gtk takes 40 seconds to make windows appear, but it starts
(X11-related?) network activity after only 25 seconds. In the strace
output, there's a 14-second timeout immediately followed by a 11-second
timeout, and no other timeouts (the other 15 seconds are probably due
to network activity).

gtk4 now uses XDG desktop portals by default. I guess you need to
figure out how to get xdg-desktop-portal working in your environment
or disable portals in gtk4 and maybe also in libadwaita. There are
environment variables you can use.

https://docs.gtk.org/gtk4/running.html suggests GDK_DEBUG=no-portals

Thank you,
Jeremy Bícha

"export GDK_DEBUG=no-portals" has no effect.

Note that the startup time has apparently reduced to around 15 seconds
(whether GDK_DEBUG=no-portals is used or not), which is still large.

Does also setting ADW_DISABLE_PORTAL=1 help?

Thank you,
Jeremy Bícha

No, still the same issue.