Freezing in windows

i have a gtk3 program written in golang using gotk3 lib
i have cross compile it using fedora docker (i followed the wiki guide here)
when testing the exe in windows i get the following error:
Gtk:ERROR:…/gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load C:\Users\USER\projects\PROJECT\share\icons\Adwaita\scalable/status\image-missing.svg: Unable to load image-loading module: C:\Users\USER\projects\PROJECT../lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll: ’ C:\Users\USER\projects\PROJECT../lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll’: The specified module could not be found. (gdk-pixbuf-error-quark, 5)

i found deleting the lib folder will solve this issue but sometimes when launching the exe it freezes (about 6/10 tries it freezes)
how can i fix that

Hi,

It’s hard to say… I’m using gtk on Windows too (though not with Go, but with C, Vala and Python) and never faced such freezes.

Ideally, try to connect a debugger and break during the freeze to check the backtrace.

If you don’t have a debugger, try to print some debug messages from your code to try to figure out where it’s stuck. You may also try to set gtk’s debug environment variables.

it stucks at gtk main loop
this only happen in windows and compatibility wont fix it
EDIT:i have set the inspecter to true when the program freezes it freezes too

I tried gtk 3.23 (i was using gtk 3.24)
the freezing problem exist but in a different way
in 3.24: the window loads after that it freezes
in 3.23:for some reason there will be 2 instance of the program non of the load the window both are freezed (one of them has the icon i set in the code the other uses default gtk icon but sometimes both of them uses gtk default icon)
Note: in 3.23 only when the 2 instance exist it freezes when the there is only one it work fine

GTK 3.23 is a development branch from 2018; testing it is meaningless.

It’s much more likely an interaction between Go and GTK on Windows.

Hello @ahmedali, could you try that:

  1. Download SysInternals Process Explorer
  2. Reproduce the freeze
  3. Get a stacktrace (no need for symbols) of the thread with Start Address as <app>.exe

ntoskrnl.exe!KeSynchronizeExecution+0x6fa6
ntoskrnl.exe!KeWaitForSingleObject+0x1460
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!IoGetIoPriorityHint+0x164d
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x401
ntoskrnl.exe!KeWaitForSingleObject+0x1787
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!ObWaitForSingleObject+0x91
ntoskrnl.exe!NtWaitForSingleObject+0x6a
ntoskrnl.exe!setjmpex+0x8648
ntdll.dll!ZwWaitForSingleObject+0x14
KERNELBASE.dll!WaitForSingleObjectEx+0x8e
app_gtk_3_23.exe+0x7229a

the trace is the same for gtk 3.24

EDIT:I dont know if it is related to freezing or not but the stack trace is different when the program run normal. The 1st one
ntoskrnl.exe!KeSynchronizeExecution+0x6fa6
ntoskrnl.exe!KeWaitForSingleObject+0x1460
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!IoGetIoPriorityHint+0x164d
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x401
ntoskrnl.exe!KeWaitForSingleObject+0x1787
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!ObWaitForSingleObject+0x91
ntoskrnl.exe!NtWaitForSingleObject+0x6a
ntoskrnl.exe!setjmpex+0x8648
ntdll.dll!ZwWaitForSingleObject+0x14
KERNELBASE.dll!WaitForSingleObjectEx+0x8e
app_gtk_3_24.exe+0x7229a

the 2nd one
ntoskrnl.exe!KeSynchronizeExecution+0x6fa6
ntoskrnl.exe!KeWaitForSingleObject+0x1460
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!IoGetIoPriorityHint+0x164d
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x401
ntoskrnl.exe!KeWaitForSingleObject+0x1787
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForMultipleObjects+0x2be
ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0
win32kfull.sys!memcmp+0x113a
win32kfull.sys!+0x101e
win32k.sys!EngSaveFloatingPointState+0x28df
ntoskrnl.exe!setjmpex+0x8648
win32u.dll!NtUserMsgWaitForMultipleObjectsEx+0x14
USER32.dll!MsgWaitForMultipleObjectsEx+0x9e
libglib-2.0-0.dll!g_pattern_match_simple+0x132
libglib-2.0-0.dll!g_pattern_match_simple+0x4fa
libglib-2.0-0.dll!g_poll+0x35c
libglib-2.0-0.dll!g_get_monotonic_time+0x910
libglib-2.0-0.dll!g_main_loop_run+0x120
libgtk-3-0.dll!gtk_main+0x7e
app_gtk_3_24.exe+0x7062d
app_gtk_3_24.exe+0x706a3
app_gtk_3_24.exe+0x9132
app_gtk_3_24.exe+0x218aa9
app_gtk_3_24.exe+0x74c334
app_gtk_3_24.exe+0x756af4
app_gtk_3_24.exe+0x4070b
app_gtk_3_24.exe+0x70a61

1 Like

Thanks! There isn’t a frame with GTK or GLib here, are you linking statically with GTK3?

i dont think so all files are .dll and .exe

Yeah, as can be seen from the other stack traces you posted. Ok, so it seems that GTK is not involved here.

Is your GO application built with debug info’s? That way we can check which line corresponds to app_gtk_3_23.exe+0x7229a (using mingw-w64 addr2line)

Open a terminal emulator in Fedora and launch:

x86_64-w64-mingw32-addr2line -e /path/to/app_gtk_3_23.exe 0x7229a

i tried to compile with debug info i got the following error:
In file included from /usr/include/glib-2.0/gio/gio.h:48,
from …/…/pkg/mod/github.com/gotk3/gotk3@v0.6.3/glib/application.go:3:
/usr/include/glib-2.0/gio/gcredentials.h:77:1: error: unknown type name ‘uid_t’; did you mean ‘pid_t’?
77 | uid_t g_credentials_get_unix_user (GCredentials *credentials,
| ^~~~~
| pid_t
/usr/include/glib-2.0/gio/gcredentials.h:81:52: error: unknown type name ‘uid_t’; did you mean ‘pid_t’?
81 | uid_t uid,
| ^~~~~
| pid_t
the command i use to compile is
CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc GOOS=windows GOARCH=amd64 go build -ldflags -H=windowsgui -gcflags=“all=-N -l -l” --tags “fts5” -o bin/app_debugging.exe cmd/main/main.go

Ah, don’t worry about the GTK libraries :slightly_smiling_face: only the app (.exe) must have debug info’s. And most probably it’s already ok, see c - How to build a release version binary in Go? - Stack Overflow

Try lanching that command in a Fedora environment:

x86_64-w64-mingw32-addr2line -e /path/to/app_gtk_3_23.exe 0x7229a

the output is weird
??:0
btw i use fedora in docker the host is endeavouros i only use windows 10 as a testing env

Could it be that the app was built with go build -ldflags="-s -w"? Or maybe deployed with go install -ldflags '-s'?

See Debugging Go Code with GDB - The Go Programming Language

no i used the same commands written in gotk3 cross compiling using fedora docker but i only cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/*.dll and cp -r /usr/x86_64-w64-mingw32/sys-root/mingw/share
since copying other folders and files wont change the state

1 Like

Turns out addr2line is broken for all PE targets…

well what i understood from our previous tries is that the problem is with my code and not a gotk3 lib, right?
if so what is the most common causes of freezing in gtk main loop? (i have a print statment to print the launch time its before the gtk.main method)

The main loop it the one processing input events and drawing the widgets.
GTK is event driven, so if the mainloop gets stuck, it means there is either a long processing ongoing or a lots of high-prio events being processed.

well i have a sqlite db connected to the app i query some data from it and load it as a gtklistbox before the gtk main could that be relative?
even tho in my testing rn i am using an empty database so its not a long procces to make it freeze
EDIT:i dont really think that the case since there is no freezing in linux

On Windows, some antivirus softwares may consider the SQL accesses as suspicious activity and freeze to analyze.

By the way, how do you run the gtk mainloop? Do you use a GtkApplication?