Need to get all the debug of GTK2 in Windows

Platform
#1

Yes, first of all, I know GTK+2 is obsolete.

Second, I’m not developer, but yes a tester, so if I question something stupid I expect don’t to bother anyone.

I wanted to fix a ReactOS bug (that is a Windows NT clone) that involves software (f.e. Ardour, GIMP, some GTK-demo bundles and etc) that should work under Windows XP. Probably located inside the USER32, Win32k.sys libraries, and related to gdk-win32+intdl, or some of those libraries, but it’s really difficult to dig into it because of the complex libraries that GTK+ have and the silence of the output in that release programs.

It is stacking in a bucle that shows a cursor clock “thinking” and freeze the window.

I really want to know how to get the bt, under Windows as possible, and every single detail of the software that potentially could help me. I have seen some tickets that talks about gdb.exe that is in a MinGW repo, but I haven’t found the point to make it work.

To add more info, I took a look into a workaround that in a concrete version of the GTK+ Win32 Bundle, allows me to get into the quoted software (Ardour, GIMP, GTK-demos and etc).

Thanks you really much.

#2

Hi! As a start you can check if process explorer runs on ReactOS. It is able to get an instant stack trace at any moment of a running application. Shouldn’t it run then I’d try with gdb. Anyway you should really ask ReactOS developers for guidance on debugging in ReactOS! See:

What version of GIMP are you working on?

#3

I’m using GIMP 2.8.22, Ardour from 5.12 to 6.9, and others.

I tried to make a full ReactOS bt, but the issue is not correctly detailed, because of the bit tones of interdependencies that GTK+ have.

I made a ticket about Ardour’s, but they have a 7 years old ticket in JIRA about GIMP, and I want to get, at least, why it’s failing.

The failure is not splashing substantial errors in the log at all, neither breaks or messages. And I’m sure that the GTK+ is not splashing all the functions in the log.

#4

Ok. Do you get the function names in the backtrace? If not it may be worth to recompile at least one DLL with debug symbols. Anyway just post here the backtrace and we’ll see the best way to move forward

#5

I get a system full log, but a really tiny bt, because the program itself doesn’t break at all. And I get the GDB output, GTK GDB output (User32) - Pastebin.com.

All the failure one quote some libraries such like libglib or gdk-win32 and functions like gdkWindowToplevel and GdkClipboardNotification, even some files like , but without clearness.

The debugchannel all in ReactOS give me too much verbose things, but the same clearness. Maybe I have to compile the GTK libraries with debugsymbol activated? If so, I need instructions to do it (I think it won’t be as easy as compiling a little app).

#6

Recompiling some dependencies won’t be super easy, no, but can be done! :wink: You say that the program hangs, right? Then we should get a stack trace of the program in that situation. Can you try if Process Explorer works on ReactOS?

#7

Yes, the program hangs. About process ex, noup, it died. But I have all the process in the debugger in ROS, or remotelly in my Windbg or Putty, and I can partially perform IDA Pro to run.

#8

Well, actually the Process Explorer 10 works.

#9

Great! The next step is to capture a stack trace of the GIMP threads using the debugger.

See windows - How can I view the call stack of a running process/thread? - Super User. You can entirely skip the symbols paragraph as it’s not needed here.

#10

Here I have the capture of the thread stack that I could get with my ROS device machine. It hangs like a zombie.

Also, I got here the capture about what I have from the “working” workaround (subtitution of the libgdk-win32 and intl.dll from the GTK+bundle 2.24.10) that makes the software to run.

#11

Hi:
Updates: With the help of a estimated mate, I encountered that something is wrong with some of this libraries:
libintl-8.dll, libiconv-2.dll,libgcc_s_dw2-1.dll.
The libgdk-win32-2.0-0.dll that is developed to work with libintl-8.dll make it crash only under ROS, instead of the libgdk-win32-2.0-0.dll developed to work with intl.dll. How can I get information about what is failing? Where I can find this libraries with debug symbols and all the verbosity needed?

#12

If you need debug symbols you should recompile the libraries. It can be done natively on Windows using configure + make and GCC (maybe you can start with MSYS2) or alternatively you can cross-compile from a Linux system.

I don’t quite get what you want to do, though. You say that GIMP with a specific libgdk-win32.dll is working fine, so what exactly are you investigating?

#13

I’m trying to investigate why the “usual” GIMP libraries (libgdk-win32-2.0-0.dll that load the libintl-8.dll) stay in a infinite bucle (that shows like a sandclock cursor) in ROS (and under Windows Whatever version works as usual). I got the clue about an approximation of what is failing trying the workaround (libgdk-win32-2.0-0.dll from the bundle that loads intl.dll).

Here I have the example in video with Ardour: Ardour issue ReactOS - YouTube

It’s a mess because it’s not breaking at all, and I get a pretty null bt. Only a reference to the libglib, and nothing else that can help me.

It’s a failure in ROS dll gdi32, winsrv, user32 and/or win32k.sys, but I need to know what is exactly failing (functions, imports and exports). Maybe the debug symbol libraries could help me. But I need exactly the crashing ones (so not the ones that became in the GTK bundle).

#14

Finally, after nearly a month, the issue is solved under ReactOS. It was an issue with the User32 that wanted a version compiled for win2000 and GIMP is compiled for WinXP at least.
GetQueueStatus and QS_ALLINPUT failed.
It’s fixed as described in
https://jira.reactos.org/browse/CORE-15686
if anyone wants more info.
Thanks you really much! Gimp is usable (with minor bugs, but runs!)

1 Like
#15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.