I can reliably crash Geany 1.33 (and previous versions) by the following commands. 1. "File->Open" (or any other method) to display the open file dialog. 2. Shift+RightClick on a directory, and select "Copy as Path". 3. Wait. A crash will occur.
Note: the crash occurs sooner if you paste the copied path anywhere, for instance into the open "untitled" window, or where I first encountered the crash: open a cmd window, enter "cd /d " and paste the copied path.
The event viewer displays "Event 1000, Application Error" and the following info:
`Faulting application name: geany.exe, version: 1.33.0.0, time stamp: 0x00000000` `Faulting module name: libgdk-win32-2.0-0.dll, version: 2.24.32.0, time stamp: 0x00000000` `Exception code: 0xc0000005` `Fault offset: 0x00026472` `Faulting process id: 0x18f0` `Faulting application start time: 0x01d44284f527cbc7` `Faulting application path: C:\Program Files (x86)\Geany\bin\geany.exe` `Faulting module path: C:\Program Files (x86)\Geany\bin\libgdk-win32-2.0-0.dll` `Report Id: 056c8fd0-6756-4c2a-a813-32ce3f030269` `Faulting package full name: ` `Faulting package-relative application ID:`
systeminfo displays the following:
`OS Name: Microsoft Windows 10 Home` `OS Version: 10.0.17134 N/A Build 17134` `OS Manufacturer: Microsoft Corporation` `OS Configuration: Standalone Workstation` `OS Build Type: Multiprocessor Free`
My WAG is that this relates to the allocation, permissions, or ownership of the paste buffer.
Probably a duplicate of #1937
Actually unrelated to #1937 as the issue here is related *only* to native Windows file open dialogs.
gdb backtrace: ``` Program received signal SIGSEGV, Segmentation fault. 0x6c560e76 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll (gdb) bt #0 0x6c560e76 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #1 0x6c5610bd in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #2 0x6c5611d1 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #3 0x6c57a532 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #4 0x6c57c211 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #5 0x6c57d372 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #6 0x76e462fa in gapfnScSendMessage () from C:\Windows\syswow64\user32.dll #7 0x000a038e in ?? () #8 0x76e46d3a in USER32!GetThreadDesktop () from C:\Windows\syswow64\user32.dll #9 0x6c57d300 in ?? () from c:\Program Files (x86)\geany\bin\libgdk-win32-2.0-0.dll #10 0x76e46de8 in USER32!GetThreadDesktop () from C:\Windows\syswow64\user32.dll #11 0x00000000 in ?? () ```
No idea what's happening there. There seems to be no Geany code involved, only Windows and GTK/GLib APIs. I'm afraid we can't fix that.
@eht16 well, both are crash in GTK/GDK when the filesystem entity that they have open is changed was my thinking.
Thanks for the analysis. I have not done any debugging of this type in more than 20 years, so pardon me if I have some dumb questions.
Does the Geany build build the libgdk DLL, or use a prebuilt or downloaded version? If you build, would it be reasonable to build libgdk with debugging information, so we could narrow down the part of libgdk involved, with the intent to raise an issue with GTK. (later) On the [wiki](https://wiki.geany.org/howtos/win32/msys2), it sounds like prebuilt runtime files are used.
I have the mingw tool chain installed as part of cygwin. Any idea if this would work instead of msys2?
Does geany build for windows x64? Does it build with GTK 3? Will it use Python3? (I don't use python2 anymore.)
`$ file geany.exe` `geany.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows` Is the "external PDB" available for download? And can gdb use it?
Closed #1942.
Reopened #1942.
oops
Does the Geany build build the libgdk DLL, or use a prebuilt or downloaded version?
It uses a pre-built one from the MSYS2 project. We do this because building GTK on windows isn't easy or fast. If you want to try, the instructions are on the GTK website but IIRC are for GTK3, not sure if they apply to GTK2.
@eht16 why doesn't windows build use GTK 3.22 now its "stable"?
I am now using Geany 1.38beta1 where I still get a similar error.
``` Event 1000, Application Error Faulting application name: geany.exe, version: 1.38.0.0, time stamp: 0x00000000 Faulting module name: libcairo-2.dll, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x0000000000050f63 Faulting process id: 0x5cc0 Faulting application start time: 0x01d7a7903172f154 Faulting application path: C:\Program Files\Geany\bin\geany.exe Faulting module path: C:\Program Files\Geany\bin\libcairo-2.dll Report Id: a9229c8e-b105-4ee9-942b-d91cda28f20e Faulting package full name: Faulting package-relative application ID: ```
Event 1001, Windows Error Reporting ``` Fault bucket 2283255357012743002, type 4 Event Name: APPCRASH Response: Not available Cab Id: 0
Problem signature: P1: geany.exe P2: 1.38.0.0 P3: 00000000 P4: libcairo-2.dll P5: 0.0.0.0 P6: 00000000 P7: c0000005 P8: 0000000000050f63 P9: P10:
Attached files: \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3093.tmp.dmp \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER3288.tmp.WERInternalMetadata.xml \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER32A8.tmp.xml \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER32B6.tmp.csv \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER32D6.tmp.txt
These files may be available here: \?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_geany.exe_26977968958f21542945692138e62ba1f1f38e_cac433d4_75b2f4f1-c7a7-445d-aad1-02184bc40436
Analysis symbol: Rechecking for solution: 0 Report Id: a9229c8e-b105-4ee9-942b-d91cda28f20e Report Status: 268435456 Hashed bucket: 301f7e832f0cf7bdffafc0a66640935a Cab Guid: 0 ```
Running "gdb geany.exe" in Msys2 shows (after a bunch of startup stuff) and doing a Copy as path from a windows style open file dialog:
``` Thread 1 received signal SIGSEGV, Segmentation fault. 0x00007ffe8ac30f63 in ?? () from /c/Program Files/Geany/bin/libcairo-2.dll (gdb) bt #0 0x00007ffe8ac30f63 in ?? () from /c/Program Files/Geany/bin/libcairo-2.dll #1 0x00007ffe8aac0b34 in ?? () from /c/Program Files/Geany/bin/libgdk-3-0.dll #2 0x00007ffe8aac0d7d in ?? () from /c/Program Files/Geany/bin/libgdk-3-0.dll #3 0x00007ffe8ca570e3 in ?? () from /c/Program Files/Geany/bin/libgobject-2.0-0.dll #4 0x00007ffe8ca6ee9b in ?? () from /c/Program Files/Geany/bin/libgobject-2.0-0.dll #5 0x00007ffe8ca6efe8 in ?? () from /c/Program Files/Geany/bin/libgobject-2.0-0.dll #6 0x00007ffe8aab8b46 in ?? () from /c/Program Files/Geany/bin/libgdk-3-0.dll #7 0x00007ffe8aaa3382 in ?? () from /c/Program Files/Geany/bin/libgdk-3-0.dll #8 0x00007ffe8a7ec4f5 in ?? () from /c/Program Files/Geany/bin/libglib-2.0-0.dll #9 0x00007ffe8a7e87bf in ?? () from /c/Program Files/Geany/bin/libglib-2.0-0.dll #10 0x00007ffe8a7eba46 in ?? () from /c/Program Files/Geany/bin/libglib-2.0-0.dll #11 0x00007ffe8a7ebf6c in ?? () from /c/Program Files/Geany/bin/libglib-2.0-0.dll #12 0x00007ffe8a1e269d in ?? () from /c/Program Files/Geany/bin/libgtk-3-0.dll #13 0x00007ffe8caf90c7 in main_lib () from /c/Program Files/Geany/bin/libgeany-0.dll #14 0x00007ff6cf951553 in ?? () #15 0x00007ff6cf9513b1 in ?? () #16 0x00007ff6cf9514c6 in ?? () #17 0x00007fff00f97034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL #18 0x00007fff012c2651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll #19 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) ```
I will help sort this out any way I can. I do have a work around that avoids this issue, but the direct way is, of course, much faster.
@eht16 perhaps the native dialogs should use the [GTK3 approved](https://docs.gtk.org/gtk3/class.FileChooserNative.html#typical-usage-gtkfile...) way of running them instead of direct calls to the Win32 API which probably is doing something GTK doesn't understand.
@elextr didn't know about the `FileChooserNative`, thanks. I tried it (in an quick'n'dirty attempt) but it looked just as the normal GTK3 file chooser dialog, so obviously I did it wrong.
@djhenderson: - we use prebuilt GTK, GDK and so on libraries from MSYS2 - as far as I know there are no debug symbols available
I still don't know what is causing the crash and how to easily debug it. Furthermore, I'm not willing to spend the necessary amount of time to entirely debug this, it probably would involve compiling the GTK manually to get debug symbols and more knowledge about the Win32 API regarding the file chooser dialog. I'm not a Windows user nor an expert on this OS.
Not sure what your exact use case is but copying the full path of a file is also possible the standard GTK3 file dialog by right clicking (no Shift necessary) a file or directory and choose "Copy location". Alternatively, the "Addons" plugin has an option to show a "Copy File Path" in Geany's Tools menu which does the same.
It might be better to remove the Windows native dialogs altogether instead of trying to fix their bad integration.
but it looked just as the normal GTK3 file chooser dialog, so obviously I did it wrong.
Possibly cross building is confusing it? Or possibly msys2 isn't built with the native dialogs? Or I don't have a clue what I'm talking about (probably number 3).
It might be better to remove the Windows native dialogs altogether instead of trying to fix their bad integration.
Certainly calling them directly without any integration with the GTK mainloop is always likely to cause issues, the mainloop can still run and callback Geany code while its waiting for the dialog, which is dangerous because Geany isn't written to permit that.
github-comments@lists.geany.org