Geany version 1.37 "Wolbam" (built on or after 2020-11-09) Using GTK+ v3.24.5 and GLib v2.58.3 runtime libraries
Linux wirth 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
Computer is an old ASUS Gigabyte box with 4 gigabytes of RAM and a 128 gigabyte SSD.
When Geany is started from a terminal, it takes a couple of minutes to open all project files (166 in this example) and operates correctly for normal activities. Attempting to close the project (menu: Project -> Close) goes through the motion of closing files individually, probably all of them but the failure might be occurring partway through. Geany terminates and leaves only a message stating "segmentation fault" in the starting terminal.
I start Geany from a desktop link under usual operation but there is no information after the failure that way.
A variety of projects with smaller open file counts behave correctly. I don't know where the file count threshold might be.
It is possible to close all files separately, then close the project, with the intent to open another. The result is a project file with no record of files in the project which must be re-opened manually. But using the menu: File -> Close All fails in the same way.
A separate project with 47 open files will open and close correctly without Geany terminating. The project file still has the file list available for next project open.
Possibly a related fault: sometime the close project for a smaller project will go through the motions of closing all files but will leave them still open. I have no more information on when it might happen.
Thanks for providing the detail of Geany and the system, but next time you can just copy from the top of "Help->Debug messages" to get it all in one go.
Certainly opening and closing projects with large numbers of files works for other people.
First thought from segfault is running out of memory, you don't say how big your files are, but in-memory files use about 2.5-3 times their size to accommodate highlighting and symbols and editing space. And at save it takes a copy from the buffer to make it contiguous, and if encoding to non-UTF-8 makes another copy which is then written. Whilst these copies are freed that doesn't mean the memory system will re-use them, that depends on their sizes. So memory use is likely to grow during saving many files.
Since it doesn't happen to anyone else, can you run Geany under gdb and when it fails get a backtrace `bt` and paste here, note you may need to press return several times to get all of it.
The apparent leaving files open (actually they are closed and opened again) happens when the user session file list matches the project session file list. See #267.
Help->Debug Messages provides a list of files opened during startup, plus a few other notes. The last two entries were: ``` 07:19:43: GLib DEBUG : posix_spawn avoided (child_setup specified) 07:19:43: GLib DEBUG : posix_spawn avoided (child_setup specified) ``` It seems the message content did not survive the crash and all that shows is from a restart of Geany.
My file count was 166, not counting Geany own-use files. All are text files (various languages) in UTF-8. The total byte count for the complete project (281 files) is 2.857 megabytes and I have never had all of them in an open Geany session. That byte count is from the scc program. I had checked memory usage and at the time only 1.8 GB of 3.8 GB available was in use, so running out of memory is not likely to be the source of the fault.
I have not yet used gdb to diagnose further because I don't know it and will need to take time for that.
I tried a variety of trial to start Geany, with existing open project, close project resulting in crash. I have many projects and the failure has been evident in large file counts (120+). But I tried a small project with 14 files and had a crash first time. I have not been able to repeat it, suggesting Geany might be reading uninitialised memory.
It seems that taking some actions within Geany will clear the issue and it operates as expected. I have not clearly identified a set of operations prior to failure.
I read #267 and conclude that i need "Use project-based session files" activated for my normal use case. I don't want to reload manually a long list of files within each project on each switch to it.
More to come later.
I have not yet used gdb to diagnose further because I don't know it and will need to take time for that.
Given the other information you provided above that would appear to be the only other way forward.
github-comments@lists.geany.org