geany
geany copied to clipboard
geany
Geany crashes when opening many files at once
When opening many files at once by selecting them in the file open dialog on windows 10, geany simply crashes to the desktop with no message at all.
I don't know the exact number of files, but I'm sure that under 10 files it never happens, and over 30 files it always happens.
Without more info its hard to help you, but I'm pretty sure Windows users have opened more than 30 files.
The problem does happen only if you select many files to open at once in the file open dialog. I was NOT telling that Geany crashes if you have opened many files, it crashes only if you try to open many files IN A SINGLE OPEN operation!
What other info can I give you to help pinpointing the problem?
I'm using Geany last version, 1.38 on windows 10 latest release.
Sorry, now I tested this again now and it's not crashing but refuses to load one of the files giving this error:
Could not open file "path_to_filename(some chinese chars instead of the correct file extension)" (Error when getting information for file "path_to_filename(some chinese chars instead of the correct file extension)": no such file or directory
this does NOT happen if the very same file is opened as a single file!
What locale is set? Do the filenames (that fail) have any non-ASCII characters in them? Are the filenames stored in a different encoding?
Geany locale is en ; the filenames have no non ascii char, and the file content is utf-8 encoded php and html source code.
I cannot reproduce on Windows 7 with about 60 PHP files and 50 C files. All files open properly, from the GTK file dialog as well as from the native Windows file dialog and also using Drag'n'Drop from the Windows Explorer.
I'm wondering about the Chinese characters you mentioned. Do you have any idea where they might come from? Could you provide the full debug log (Help->Debug Messages) and maybe a list of the filenames?
I'm wondering about the Chinese characters you mentioned.
Those could be ANSI file paths being rendered as multi-byte streams; forcefully casting a char * to a wide string produces that effect:
@ShoresOfNowhere, have you checked whether Unicode encoding has been activated on your PC?
- Press ⊞ (Windows key) + R
- Enter
intl.cpl - Click the "Administrative" tab
- Click "Change system locale..."
- Look for "Beta: Use Unicode UTF-8 for worldwide language support"
Sorry for the delay, I wasn't connected; Checked the setting you told me, it was and it is unckeched.
Here's the "official" explanation, courtesy of Raymond Chen:
Putting ASCII alphabetics in the high-order byte of UTF-16 code units results in nonsense Chinese characters https://devblogs.microsoft.com/oldnewthing/20220328-00/?p=106401
@ShoresOfNowhere you said that the setting @rdipardo mentioned was unset, did you set it and see what happened?
Also you said the locale was en but thats not a full locale, a full locale is something like en_US.UTF-8. What is the complete locale?
Which Geany open dialog are you using? The GTK one or the windows native one? (Edit->Preferences->General->Miscellaneous->Use Windows Native Dialogs`)
Hello! I have files listed below in a folder and geany crashes when loading all. Doesnt matter if they are empty (echo or type NUL > filename) or real registry files (reg export KEY FILENAME). It must be names. No troubles with files named 01.txt - 20.txt (total 20 txt files opened without crash). W7x64. And when selecting 3 files - 04, 05, 06, program doesnt crash but opens only 2 and gives error. HTH.
01_Classes_CLSID_{031E4825-7B94-4dc3-B131-E946B44C8DD5}.reg
02_Classes_Wow6432Node_CLSID_{031E4825-7B94-4dc3-B131-E946B44C8DD5}.reg
03_Microsoft_Windows_CurrentVersion_Explorer_Desktop_NameSpace_{031E4825-7B94-4dc3-B131-E946B44C8DD5}.reg
04_Microsoft_Windows_CurrentVersion_Explorer_FolderDescriptions_{2112AB0A-C86A-4ffe-A368-0DE96E47012E}.reg
05_Microsoft_Windows_CurrentVersion_Explorer_FolderDescriptions_{491E922F-5643-4af4-A7EB-4E7A138D8174}.reg
06_Microsoft_Windows_CurrentVersion_Explorer_FolderDescriptions_{7b0db17d-9cd2-4a93-9733-46cc89022e7c}.reg
07_Microsoft_Windows_CurrentVersion_Explorer_FolderDescriptions_{A302545D-DEFF-464b-ABE8-61C8648D939B}.reg
08_Microsoft_Windows_CurrentVersion_Explorer_FolderDescriptions_{A990AE9F-A03B-4e80-94BC-9912D7504104}.reg
09_Microsoft_Windows_CurrentVersion_Explorer_HideDesktopIcons_NewStartPanel.reg
PS. Just remembered that I had also bunch of real registry files, but named as "disable_this_setting.reg", "remove-this_thing.reg" etc. This is the result
---------------------------
geany.exe - Application Error
---------------------------
The instruction at 0xfd855250 referenced memory at 0xffffffff. The memory could not be read.
Click on OK to terminate the program
---------------------------
OK
---------------------------
@yekb @ShoresOfNowhere Since the Geany devs can't reproduce the problem somebody who can reproduce it needs to run geany with the GNU debugger and get a backtrace when it crashes.
Made some progress as far as reproducing the random Chinese and the failure to open more than 2 or 3 files.
Most importantly, I can't get the GTK file dialog to reproduce any aspect of the issue, so disabling the native Windows file dialog at "Edit > Preferences > Miscellaneous" is probably all that's needed to work around it.
With the native file chooser open, I select a bunch of full paths between 110 and 120 characters each. I set a breakpoint in win32_show_document_open_dialog() where it loops over multiple selections. At a glace ^1, it seems the file paths are accumulating beyond the capacity of MAX_PATH. For the first 3 files, stepping through with GDB shows nothing interesting:
Thread 1 hit Breakpoint 1, win32_show_document_open_dialog (parent=0x2245abd4df0, title=0x7ff9fb384e24 <__func__.0+756> "Open File", initial_dir=0x0) at win32.c:456
456 g_snprintf(file_name, 511, "%s\\%s", dir_name, tmp);
(gdb) step 2
document_open_file (locale_filename=0x9af77fe1b0 "C:\\Users\\Rob\\source\\repos\\workspace\\samples\\geany\\01_Classes_CLSID_{031E4825-7B94-4dc3-B131-E946B44C677D5}.reg", readonly=0, ft=0x0, forced_enc=0x0) at document.c:913
913 return document_open_file_full(NULL, locale_filename, 0, readonly, ft, forced_enc);
(gdb) continue
Continuing.
Thread 1 hit Breakpoint 1, win32_show_document_open_dialog (parent=0x2245abd4df0, title=0x7ff9fb384e24 <__func__.0+756> "Open File", initial_dir=0x0) at win32.c:456
456 g_snprintf(file_name, 511, "%s\\%s", dir_name, tmp);
(gdb) step 2
document_open_file (locale_filename=0x9af77fe1b0 "C:\\Users\\Rob\\source\\repos\\workspace\\samples\\geany\\01_Classes_CLSID_{031E4825-7B94-4dc3-B131-E9346B44C8DD5}.reg", readonly=0, ft=0x0, forced_enc=0x0) at document.c:913
913 return document_open_file_full(NULL, locale_filename, 0, readonly, ft, forced_enc);
(gdb) continue
Continuing.
Thread 1 hit Breakpoint 1, win32_show_document_open_dialog (parent=0x2245abd4df0, title=0x7ff9fb384e24 <__func__.0+756> "Open File", initial_dir=0x0) at win32.c:456
456 g_snprintf(file_name, 511, "%s\\%s", dir_name, tmp);
(gdb) step 2
document_open_file (locale_filename=0x9af77fe1b0 "C:\\Users\\Rob\\source\\repos\\workspace\\samples\\geany\\02_Classes_Wow6432Node_CLSID_{031E4825-7B94-4dc3-B131-E946B44C8DD5}.reg", readonly=0, ft=0x0, forced_enc=0x0) at document.c:913
913 return document_open_file_full(NULL, locale_filename, 0, readonly, ft, forced_enc);
(gdb) continue
Continuing.
The trouble starts at file number 4, which is incompletely copied to the file_name buffer:
Thread 1 hit Breakpoint 1, win32_show_document_open_dialog (parent=0x2245abd4df0, title=0x7ff9fb384e24 <__func__.0+756> "Open File", initial_dir=0x0) at win32.c:456
456 g_snprintf(file_name, 511, "%s\\%s", dir_name, tmp);
(gdb) step 2
document_open_file (locale_filename=0x9af77fe1b0 "C:\\Users\\Rob\\source\\repos\\workspace\\samples\\geany\\02_Classes_Wow6432No▒\210▒▒\215▒慬▒\215▒▒\215▒▒\235▒▒\235▒▒\220▒▒\210▒潎裣▒\215藦▒\215跧▒\235鷧▒\220裣躽▒\217▒낒뻩▒\215ꚗ黮趎럨ꖖ뻩▒\235ꞷ軮邚▒"..., readonly=0, ft=0x0, forced_enc=0x0) at document.c:913
913 return document_open_file_full(NULL, locale_filename, 0, readonly, ft, forced_enc);
Geany's debug output pipes up at the same time:
Geany: utils_str_middle_truncate: assertion 'g_utf8_validate(string, length, NULL)' failed
The Status window, trying to display the truncated file path, shows the garbled Chinese that @ShoresOfNowhere reported. I can't paste it here because trying to copy it with the widget's context menu fails with another error:
(geany.exe:8508): Pango-WARNING **: 21:52:53.958: Invalid UTF-8 string passed to pango_layout_set_text()
Still no crash, but then my file list wasn't extreme, and I compiled with zero optimization (-O0).
@rdipardo ok, so the windows native dialog returns multiple filenames in one buffer, but it truncates the last one when it won't fit, yuck!! How are they supposed to work in that case? How does the caller know what length buffer to pass to it? No wonder MS deprecates those dialogs. [end rant]
Can they be forced to only select one file which "should" be safe if inconvenient?
Or if "somebody" wanted to update the native dialog handling to use the newer MS dialogs which return multiple results in arrays of pointers to strings.
Although that effort might be wasted if Geany ever moves to GTK4 since (IIUC) native dialogs are not supported by it.
@rdipardo and @elextr sorry for responding late!
I confirm the problem happens only with native dialogs (but non native ones cannot seem to sort properly by file type, as when instructed to do so, they sort by type but NOT sort secondarily by file name, as native dialogs do, making them almost unusable!).
I confirm that that setting you were talking about was OFF, and in my tests it made no difference at all if turned on or not.
About the locale, how can I confirm the locale Geany is currently using? I'm using Geany with no language installed...
Had the "Use Windows Native dialogs" checked previously, with GTK dialog no more problems. Thanks for sorting this out.
Or if "somebody" wanted to update the native dialog handling to use the newer MS dialogs which return multiple results in arrays of pointers to strings.
Unless Geany intends to support XP, it should be instantiating Windows dialogs from IFileDialog, introduced in Vista. That should really be overseen by an experienced Windows user, which tends to be a rare bird among Geany folk.
Limiting file selections to < 512 total bytes would be a miserable user experience. With GTK4 looming, it might be time to simply drop native dialogs. It's the least amount of work and will definitely prevent a recurrence of this issue.
@ShoresOfNowhere
Sadly the problem is built into the Windows native dialogs, so we can't fix it, you can either open short lists/single files from the native dialogs, or use the GTK dialogs to open lots of files.
but non native ones cannot seem to sort properly by file type, as when instructed to do so, they sort by type but NOT sort secondarily by file name
AFAICT they apply a sort on top of the existing order, so if you sort by name then by type the name order should remain.
@rdipardo
Thanks for finding the problem.
That should really be overseen by an experienced Windows user, which tends to be a rare bird among Geany folk.
Agree and agree, windows maintainers welcome.
With GTK4 looming, it might be time to simply drop native dialogs. It's the least amount of work and will definitely prevent a recurrence of this issue.
It can happen as part of the GTK4 support, but GTK4 contributors seem as rare a bird as Windows ones.
We've got #3219 to remove the native Windows dialogs (well, most of them) completly and also the corresponding setting.
Granted, this is the easiest solution but IMO also reasonable as this issue revealed, the implementation uses old APIs and has bugs. Rewriting the file dialogs to would require lots of work and more importantly someone who does it. I won't.
@elextr I have tried sorting on file name and then on type, and you're right, it gets sorted correctly, but... as soon as you use the top bar to change folder all reverts to a useless ordering!
Sorry to bother, but has anyone idea of where can I report the sorting bug in the GTK file selection dialog? Then fact that sorting isn't kept when changing directory makes it almost unusable... am I the only one that finds this terrible to the point that I'm using the OS file manager to open files in geanie so I don't have to cope with it?
am I the only one that finds this terrible to the point that I'm using the OS file manager to open files in geanie so I don't have to cope with it?
Well, maybe not the only one, but clearly most users do not have a problem since its standard GTK behaviour and there are lots of users. Perhaps most users use filename extensions to distinguish types so sorting on names is sufficient.
I have inserted an issue on GTK bug tracking:
https://gitlab.gnome.org/GNOME/gtk/-/issues/5015
@elextr ok, this seems strange to me as sorting by multiple columns is widely used in Windows and Linux file managers, so I would expect the GTK dialogs to work on the same principle, but let's see if the GTK people would consider this a real bug! :)
Your issue is slightly misleading, it has nothing to do with Geany, it happens with all GTK open dialogs, Linux, Windows, Geany Gedit, etc etc. [Edit: it even happens with MS Vscode on Linux]
Well, given that AFAICT there is no description of what the sorting is supposed to do, so I expect its not a bug, you can't have a bug for something unspecified. But they may take it as a feature request, which will be implemented in GTK4 since nothing is changing in GTK3 now.
@elextr sorry but I don't agree with you: if you click on the file name header and then on the type header, you get exactly the sorting you expect, first by type and then by file name. if you change folder this sorting isn't kept, and it reverts to only sorted by type. In my view this IS a bug: in whatever way the sorting is supposed to work, it simply can't be right that changing folder would not keep the sorting as it is!