*That sounds more like the compositor (presuming its using Wayland).*

Maybe. Why doesn't it happen with any other app?

I've found out that SciTE (another editor using GTK) freezes after a long time idle. So, this is apparently a common problem shared with all GTK apps. I don't know whether it is a problem with Wayland or not.

That's another possibility, I didn't realize. The problem is that no error appears when launching any of them from a console. I don't know how to solve this (I mean, a workaround), or at least how to give more hints to have it solved.

Yes, @elextr I'm doing that right now.

Whats the bet it doesn't hang when running under the debugger

Hahahaha... yeah, probably... let's see what happens... :-P

If the debugger said nothing then it didn't crash, and since it finished it didn't hang, so still havn't captured it.

If you find it hung under the debugger, do not close Geany, in the debugger console do ctrl-c then bt to get a backtrace.

Okay, it seems it was my fault, I was being clumsy, Anyway, I suspect that sometimes the process somehow ended.

GDB was stuck, so as you said, I pressed CTRL+C and did a backtrace:

```gdb Downloading separate debug info for /usr/lib/libvorbisenc.so.2 Downloading separate debug info for /usr/lib/libFLAC.so.12 [New Thread 0x7fffe37fe6c0 (LWP 1775079)] [Detaching after fork from child process 1775080] [New Thread 0x7ffff26306c0 (LWP 1775081)] [Thread 0x7ffff1cd66c0 (LWP 1775046) exited] bt ^C Thread 1 "geany" received signal SIGINT, Interrupt. 0x00007ffff7b13c0f in __GI___poll (fds=0x555555e7fb00, nfds=6, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 Downloading source file /usr/src/debug/glibc/glibc/io/../sysdeps/unix/sysv/linux/poll.c 29 return SYSCALL_CANCEL (poll, fds, nfds, timeout); (gdb) bt #0 0x00007ffff7b13c0f in __GI___poll (fds=0x555555e7fb00, nfds=6, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007ffff6d0b17f in () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff6cadc7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff73d8e4f in gtk_main () at /usr/lib/libgtk-3.so.0 #4 0x00007ffff7c88293 in main_lib () at /usr/lib/libgeany.so.0 #5 0x00007ffff7a39850 in __libc_start_call_main (main=main@entry=0x555555555020, argc=argc@entry=1, argv=argv@entry=0x7fffffffd988) at ../sysdeps/nptl/libc_start_call_main.h:58 #6 0x00007ffff7a3990a in __libc_start_main_impl (main=0x555555555020, argc=1, argv=0x7fffffffd988, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd978) at ../csu/libc-start.c:360 #7 0x0000555555555055 in () ```

I've been researching a bit, it seems this function waits for changes in open files, the source code compatible with the backtrace is:

```c int __poll (struct pollfd *fds, nfds_t nfds, int timeout) { #ifdef __NR_poll return SYSCALL_CANCEL (poll, fds, nfds, timeout); #else struct timespec timeout_ts; struct timespec *timeout_ts_p = NULL;

if (timeout >= 0) { timeout_ts.tv_sec = timeout / 1000; timeout_ts.tv_nsec = (timeout % 1000) * 1000000; timeout_ts_p = &timeout_ts; }

return SYSCALL_CANCEL (ppoll, fds, nfds, timeout_ts_p, NULL, 0); #endif } ```

I haven't been able to find out where `_NR_poll` is defined, though it seems it has to do with certain types of kernels.

So, I'd say that Geany wants to check if any open file has changed and is waiting for `poll()` to return, but for some reason this never happens.

Your analysis is almost right :-)

The story of my life. :-P

poll waits for file descriptors which includes things like pipes and other communication methods, like those used by the Wayland compositor or X11 to tell GTK to redraw its part of the screen.

I see. It makes sense.

Given your distro I presume its running with Wayland direct, not via xwayland, run with GDK_BACKEND=wayland geany and GDK_BACKEND=x11 geany and see if there is any difference.

I exported `GDK_BACKEND` to be *wayland*, and then run `gdb geany`, but it failed with `can't open display':

```gdb $ export GDK_BACKEND=wayland $ gdb geany (gdb) r Geany: cannot open display [Inferior 1 (process 1838926) exited with code 01] (gdb) q ```

With exported `GDK_BACKEND` to be *x11* it started correctly, I guess tomorrow I'll be able to say what happens.

I've also `run gdb` on **SciTE** to check whether it freezes or not at the same spot.

If setting GDK_BACKED to x11 solves the issue, well, I guess that is a workaround.

It seems it is the version built over Gtk:

``` pacman -Qi scite  ✔ Nombre : scite Versión : 5.3.5-1 Descripción : Editor with facilities for building and running programs Arquitectura : x86_64 URL : https://www.scintilla.org/SciTE.html Licencias : custom:HPND Grupos : Nada Provee : Nada Depende de : gtk3 ``` There is an unofficial port to Qt4, but I'm using the official package.

The binary you download form the SciTE page, does not seem to be built with QT, either:

``` $ ldd SciTE  ✔ linux-vdso.so.1 (0x00007ffc3e326000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007fdbcec00000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007fdbcf117000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007fdbcf107000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007fdbceace000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007fdbcf0c1000) ```

Anyhow that means its worth a try to see if Scite has the same hanging problem.

I tried, but the problem is that gdb showed me that the app exited. This is the same problem I had with Geany, I tried to leave it untouched but at any time I used it and then closed it. :-(

I will leave it open just before leaving work, since it is not enough for leaving it idle for a the office hours, the bug needs a whole night to trigger.

About Geany:

```bash $ export GDK_BACKEND=wayland $ gdb geany Geany: cannot open display [Inferior 1 (process 1838926) exited with code 01] (gdb) q ```

```bash $ export GDK_BACKEND=x11 $ gdb geany [Detaching after fork from child process 1839036] [New Thread 0x7fffe3fff6c0 (LWP 1839037)] [Thread 0x7ffff1cd66c0 (LWP 1839002) exited] ^C Thread 1 "geany" received signal SIGINT, Interrupt. 0x00007ffff7b13c0f in __GI___poll (fds=0x555556292f30, nfds=6, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 Downloading source file /usr/src/debug/glibc/glibc/io/../sysdeps/unix/sysv/linux/poll.c 29 return SYSCALL_CANCEL (poll, fds, nfds, timeout); (gdb) q A debugging session is active.

Inferior 1 [process 1838991] will be killed.

Quit anyway? (y or n) y ```

So, using X11 for GDK the bug triggers anyway. Trying to use Wayland directly does not allow Geany to open.

I don't suppose you got a backtrace? The line is simply the operating system call, what is important is the path to get there.

But basically it looks like the compositor message to redraw is not getting to GTK.

I don't know why, wayland does not work on your distro, on some other distros Geany works on both and often better on wayland, maybe its the Plasma compositor since GTK is aimed more at Gnome.

But using X11 means its got an extra moving part, xwayland that sits between X11 clients and wayland, but its not a perfect replica of x.org X11, its new and buggyish relative to decades olde X11. Thats what I would blame, but don't know how to check, maybe you can find out if there is a tool on Manjaro that shows messages between GTK and xwayland and see if they indeed stop.

Okay, but the backtrace does not seem (to me), to be very informative.

True, but what it shows is the fact that the only code is Geany's main calling GTK main waiting in the main loop (like the previous backtrace).

But my comment was actually in relation to your test of Scite, to see if it hung in the same place ;-P

Anyway don't bother to get a backtrace of that now, we have two apps that both hang. Seems its something in xwayland. Its a pity your distro doesn't provide a GTK with a wayland backend as well, as I noted above, often that works better than xwayland.

I've rebooted and changed into Plasma with Wayland. I've launched gdb with Geany, I guess I'll tomorrow know whether there is any change or not.

```bash $ printenv | grep -i x11  ✔ $ printenv | grep -i wayland  DESKTOP_SESSION=plasmawayland QT_WAYLAND_FORCE_DPI=96 WAYLAND_DISPLAY=wayland-0 XDG_SESSION_TYPE=wayland ```

F*ck, sorry. :-(

Everyone hits the wrong button all the time, github should move it to the other side.

: Good news: I launched Geany with GDB under Wayland, and nothing happened. I mean, Geany was happily working after the night. :-)

Neat :smile: Thank you for persisting.

So I guess you're right, it is a problem related to XWayland. It doesn't have anything to do with Geany. I don't know whether this means I should close the issue or not... Should we somehow report it upstream?

Since none of the Geany contributors have your system we can't add much since we can't replicate the problem (and also it happens with Scite as well), so its up to you, if you are happy to run the wayland session its less worth it, if you need to run the X11 session it might be worth it.

All I would note is to be very sure what configuration you are running when you report stuff, as you have seen there are a number of moving parts to this problem.

so its up to you, if you are happy to run the Wayland session its less worth it, if you need to run the X11 session it might be worth it.

Well, Wayland runs fine for me, and it seems it is also the future, so, now I'll be pushing the button on purpose. BTW, many thanks for your support.