When I disconnect/reconnect external monitors, most programs jitter for a second. Thats annoying, but normal. Sometimes (tho not always), geany will crash. Thats annoying (especially if I had unsaved documents), but ya know, stuff happens.
This is where it gets interesting.
When I relaunch geany, it will have the last-known set of files open (as of the last time I launched geany, which may have been several days earlier, if i've had it running for several days. Any files I've opened since then, are not remembered when I relaunch geany. In other words, when it crashes, it looks like it can't save its known-files, and defaults to the last-known good files). If I try to open another file while geany is open (double click in windows explorer, clicking on the firefox downloads button, or even typing "geany.exe somefile.txt" on the shell, with and without the -i option), geany will launch an entirely new instance, with that same last-known set of files, plus somefile.txt. If I try to launch a 3rd file, again, that original set of files, + 3rdfile.txt. What I want to happen, is that geany uses a single instance, and opens the file in a new tab.
I suspect that when geany initially crashes, it doesn't clean up properly, and when I relaunch it, it stumbles. No combination of closing, killing, force-killing, taskmanager-ing, ProcessExplorer-ing (3rd party Task Manager replacement), powershelling, etc, seems to resolve it. Restarting explorer.exe does not fix it Logging out and back in to Windows (with or without restarting the OS) DOES fix it, although its a huge hassle.
After the initial crash, after I restart geany, "geany.exe --list-documents" returns no documents, even tho I have an instance open with several documents open. This could be related. I'm happy to look for a straggling socket file (if I know where to look), etc.
``` PS C:\Program Files (x86)\Geany\bin> ps
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- -> omitting irrelevant results <- 371 28 14324 36092 13.55 48564 6 geany PS C:\Program Files (x86)\Geany\bin> .\geany.exe --list-documents PS C:\Program Files (x86)\Geany\bin> ```
I've been a huge fan of geany for over a decade. I'm thrilled to pieces to help troubleshoot, pull logs, run tests, etc.
I'm on windows 10, Geany 1.36.
"geany.exe -v" (lowercase v) returns this
``` Geany: Failed to connect to IPC socket (127.0.0.1:49876): 10061: No connection could be made because the target machine actively refused it. Geany: Geany 1.36, English_United States.1252 Geany: GTK 2.24.32, GLib 2.60.6 Geany: System data dir: C:\Program Files (x86)\Geany\data Geany: User config dir: C:\Users\av185120\AppData\Roaming\geany Geany: System plugin path: C:\Program Files (x86)\Geany\lib\geany Geany: Added filetype Arduino (61). Geany: Added filetype Clojure (62). Geany: Added filetype CUDA (63). Geany: Added filetype Cython (64). Geany: Added filetype Genie (65). Geany: Added filetype Graphviz (66). Geany: Added filetype Groovy (67). Geany: Added filetype JSON (68). Geany: Added filetype Kotlin (69). Geany: Added filetype Nim (70). Geany: Added filetype Scala (71). Geany: Added filetype Swift (72). Geany: Added filetype TypeScript (73). GLib-GIO: _g_io_module_get_default: Found default implementation winhttp (GWinHttpVfs) for â?~gio-vfsâ?T Geany: IPC socket could not be created, see Help->Debug Messages for details. Geany: Loaded: C:\Program Files (x86)\Geany\lib\geany\splitwindow.dll (Split Window) Geany: C:\Users\av185120\Documents\notes\notes.txt : None (UTF-8) -> A whole bunch of files I have open -< ```
Probably the link in the config directory was left when Geany crashed, so look there, should have an obvious name (with "socket" in it).
Amazingly, I actually stumbled upon the root cause and the resolution: When geany "executes" a script, it does so in a popup cmd.exe window. Now close geany, whether by crashing it with external monitors (who knows whats happening with the split second redrawing) or by simply clicking the "X" to close geany. Its child cmd.exe will be left open. This leaves some socket file somewhere that triggers the above behavior. Closing all geanys, and closing its child cmd.exe, will resolve the issue. I can consistently reproduce it with this dummy python script ```import time while True: time.sleep(5) ``` As something to hold the child cmd.exe open.
I don't know why geany sometimes crashes when connecting/disconnecting external monitors. It may be something so suble we may never know. But, geany should kill its children cmd.exe windows, or if it doesnt want to / cant (I don't know the underlying architecture) it should reopen gracefully even with a straggling cmd.exe window.
Note any cmd.exes I created myself are unrelated. Only cmd.exes that geany created are relevant. Should I create a new bug for this, since we now know its not particularly related to external monitors?
This leaves some socket file somewhere that triggers the above behavior.
That's what @elextr was referring to.
It may be something so suble we may never know.
It's pretty easy to find out what's going on with a suitable backtrace from GDB. On non-Windows systems this is trivial, but it's more of a pain on Windows.
But, geany should kill its children cmd.exe windows, or if it doesnt want to / cant (I don't know the underlying architecture) it should reopen gracefully even with a straggling cmd.exe window.
It can't kill/do anything on its way out if it's crashing with a segmentation fault. Presumably when it starts back up it cannot tell the difference between the old stale socket file and an actual existing running instance of Geany's socket file. None of this really matters though since Geany just should never crash.
Should I create a new bug for this, since we now know its not particularly related to external monitors?
The main bug is Geany crashing, once that happens all bets are off, so I'd leave this bug. Feel free to edit the title/description as you see fit.
I'm not quite sure I agree with that. Now that I know how to reliably trigger it (i've been fighting this on and off for probably close to a year..... figures that as soon as I submit a bug report, a week later a stumble upon the cause.... lol dumb luck), I can trigger it by simply closing geany with a child command window open. No crashing necessary.
If we wanted to try and capture the crash with GDB, I'm happy to help. Depending on how often I dock and undock my monitors from my laptop, it can crash every few days. Tho, I don't know how to GDB on Windows. How can I set that up?
Tho, I don't know how to GDB on Windows. How can I set that up?
There is some info in the HACKING file, not sure how windows specific it is though.
simply closing geany with a child command window open.
Works on Linux, the socket file is correctly removed.
I can't reproduce on Win10, but I'm not sure I'm doing it right.
@alexnerd123 can you please provide an idiot-proof list of steps I can perform to try and reproduce?
@codebrainz I reproduced the child command window issue on a relatively fresh window 10 VM, so I don't think its anything exotic about my machine. Steps to reproduce: launch a fresh copy of geany. Default settings are fine Execute a script such as this. I used python, but I don't think the language is important ```import time while True: print "foo" time.sleep(5) ``` The idea is, you want something that continually executes. Now, while the script is "foo"ing, close geany. The command window will stay open, and it will keep printing foo. Double click any text file from windows explorer (or right click open with geany, etc). Geany will launch your file Double click another text file from windows explorer. Geany will launch a second concurrent instance. 3rd, 4th, 5th, files will all load in their own instance Now to resolve it: close all geany instances, then close the "foo" script window. Now open a file with geany, then a 2nd, 3rd, 4th file from windows explorer, all will open in the same geany instance as expected.
Unless, of course, you meant the crashing issue? I'm not exactly "a windows guy", I'm "a linux guy" stuck on windows for my job but I think I managed to install gdb for windows, and I currently have geany running in gdb.exe, running in powershell. I'll leave it like that for a few days and see if I can capture a stacktrace from a crash. That issue is intermittent tho, so no guarantee on when I get it
As @codebrainz noted on IRC, on windows a network socket at a fixed port is used, not a named pipe as is used on Linux.
I'm not a windows expert, but maybe the spawned command window gets a copy of the handle for the network socket when its spawned, and that keeps the socket in existence after Geany is closed.
But of course attempts to talk to it will probably fail since there is no Geany on the other end and so a new instance will open.
But also do please keep looking for a backtrace for the crash.
Looks like we may have gotten lucky. I had geany running inside of gdb, inside of powershell. I docked and undocked several times. I see this error from the geany -v output ``` ** Gdk:ERROR:../../../gtk+-2.24.32/gdk/win32/gdkdisplay-win32.c:85:enum_monitor: assertion failed: (*index < _gdk_num_monitors) ``` and this is the full gdb. Its interesting, when it crashed, it somehow backfed my dummy python as if it were GDB commands..... I have no idea how that happened, but I broke out of it (ctrl C) and ran the "bt" command ``` PS C:\Program Files (x86)\Geany\bin> c:\mingw\bin\gdb.exe .\geany.exe GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mingw32". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\Program Files (x86)\Geany\bin\geany.exe...(no debugging symbols found)...done. (gdb) run -v Starting program: C:\Program Files (x86)\Geany\bin/.\geany.exe -v [New Thread 99808.0x15a08] [New Thread 99808.0x1632c] [New Thread 99808.0x12044] [New Thread 99808.0x18b78] [New Thread 99808.0x17568] [New Thread 99808.0x182e4] [New Thread 99808.0xebb4] warning: Invalid parameter passed to C runtime function.
[New Thread 99808.0x1288c] [New Thread 99808.0x17a48] [New Thread 99808.0x12dc8]
Program received signal SIGTRAP, Trace/breakpoint trap. 0x76caacc3 in KERNELBASE!DebugBreak () from C:\windows\SysWOW64\KernelBase.dll (gdb) import time Undefined command: "import". Try "help". (gdb) while True:
print "foo" time.sleep(5) import time while True: print "foo" time.sleep(5)
st Quit (expect signal SIGINT when the program is resumed)
(gdb) st Ambiguous command "st": stack, start, status, step, stepi, stepping, stop, strace. (gdb) bt #0 0x76caacc3 in KERNELBASE!DebugBreak () from C:\windows\SysWOW64\KernelBase.dll #1 0x599e8a49 in ?? () from C:\Program Files (x86)\Geany\bin\libglib-2.0-0.dll #2 0x599da052 in ?? () from C:\Program Files (x86)\Geany\bin\libglib-2.0-0.dll #3 0x599da0b6 in ?? () from C:\Program Files (x86)\Geany\bin\libglib-2.0-0.dll #4 0x6c56ecb7 in ?? () from C:\Program Files (x86)\Geany\bin\libgdk-win32-2.0-0.dll #5 0x73fbb5bb in USER32!GetDpiForMonitorInternal () from C:\windows\SysWOW64\user32.dll #6 0x76f2cd3d in ?? () #7 0x004d026c in ?? () (gdb) ```
All the thread starts and the invalid parameter were at startup, and the SIGTRAP and below is the crash
Hmmm, the crash looks like its inside GDK (a part of the GTK GUI library) trying to get the resolution of a monitor that doesn't exist (because you unplugged it :).
So not sure its something Geany can address if its GUI library aborts under it.
Steps to reproduce...
Ok, can reproduce. I also noticed for opening the 2nd file after re-opening Geany (using right-click Open With Geany menu item in Windows Explorer), that Geany doesn't launch. If I try again, it opens in a new window with the original file (same as first window) and that 2nd file, just as you described.
Unless, of course, you meant the crashing issue?
Nope, just the instance/socket issue.
----
As for the crashing in GDK, I'm not sure but if you have or want to install msys2, you could compile Geany from Git against newer GTK/GDK/etc libraries; it's possible the docking/crash has been fixed already.
Feel free to separate the Issues into two separate ones since as you said it's two seemingly unrelated things, or don't if you don't want to.
I'll see if I can try to recompile it....... I'm gonna try to compile the ubuntu flavor, on ubuntu, just to get the feel for it. Then I'll try to build the windows flavor. I don't "entirely" know what I'm doing, so it may take a while to install all the dependencies :p
github-comments@lists.geany.org