Unfortunately Geany has huge problems with built-in SFTP over Nautilus/Nemo. It hangs, freezes and/or suddenly closes. I can't really say why, since I even used `TCPKeepAlive` to keep the sessions alive, but this doesn't fix the problems.
Does Geany even support using it that way?
Essentially Geany does not know it is using anything over sftp, if just reads files, and the sftp has to be mounted so it appears as a file.
It therefore depends on the quality of the software that provides that facility, be it FUSE or some other mechanism. From the message given it would appear that rather more than 20k is being read. Perhaps the metadata (specifically file size) is being provided wrong and it is causing allocation of an insanely large buffer.
I believe it is the `gvfsd-sftp` backend from GVfs (Gnome Virtual File System) which seems to be the default for Nautilus/Nemo, I don't have FUSE installed:
``` office@office-linux:~$ uname -a Linux office-linux 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux ```
``` office@office-linux:~$ ps aux | grep sftp office 211755 0.0 0.0 398452 8640 ? Sl 09:04 0:00 /usr/libexec/gvfsd-sftp --spawner :1.9 /org/gtk/gvfs/exec_spaw/8 office 211766 0.0 0.0 26728 8480 pts/1 Ss+ 09:04 0:00 /usr/bin/ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -oControlMaster auto -oControlPath=/run/user/1000/gvfsd-sftp/%C -s server.example.com sftp office 211769 0.0 0.0 26336 7680 pts/2 Ss+ 09:04 0:00 /usr/bin/ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -oControlMaster auto -oControlPath=/run/user/1000/gvfsd-sftp/%C -s server.example.com sftp office 214503 0.0 0.0 19016 2720 pts/0 S+ 09:48 0:00 grep --color=auto sftp ```
Can Geany be hardened here to tell an error message? It must be either a bug of Geany or `gvfsd-sftp`.
I guess you are opening the file via Nautilis/Nemo, so you can't tell Geany to use filetype none. If you can open it with the Geany internal dialog there is a drop down that would allow you to set none, which should remove the calls to mio. Or rename the remote file to an extension like .nothing. Then see how big Geany thinks the file is after it has opened it.
What do you mean by filetype none? The file extension was `.php`.
Mio is part of the symbols uctags based symbols parser, so if the file is opened as filetype `none`, there will be no symbol parsing, thus removing the mio code path where it is running out of memory. If the file then opens without a crash it will be possible to see the size, and get a better idea where the problem may be.
Where to download Geany 2.1? Are you using this fork?
https://github.com/Alex313031/geany-ng/releases
No, I didn't use any fork, but used the master branch of this repository which is version 2.1:
https://github.com/geany/geany/blob/master/meson.build#L3
The problem disappeared after I switched back to 2.0 _and_ added following to my `~/.ssh/config`:
``` Host * ... ServerAliveCountMax 5 ServerAliveInterval 15 TCPKeepAlive yes ```
I've been now heavily using it and while there was a small freeze from time to time, no crashes or anything which caused Geany to become unresponsive or lose all its data as before.
Perhaps try Geany git HEAD with your SSH configuration. AFAIK there are no major changes between 2.0 and HEAD that would impact to the area that indicates it ran out of memory so its more likely the configuration, but it would be good to know that before 2.1 release.
@etkaar I would be tremendously helpful if you could try and bisect where the problem started, that could be a huge part of finding a solution! :slightly_smiling_face:
Hi! 🙂 Once I have time, I will retry it with Geany 2.1 and tell you if the SSH confi fixes it for that version as well. Nonetheless it is likely that Geany has a problem with dead `gvfsd-sftp` session or so. The SSH session times out and then something with `gvfsd` causes Geany to crash.
I just tried to see what could cause this, and all I can think of is a mishandling of a seeking failure. However, I cannot seem to reproduce the issue with my local SSH connection through Caja (which is the same underlying gvfs-fuse setup). Do you have a specific file that causes issues? or is it intermittent?
I am not sure if it is intermittent, because when I remember correct, it even took a few days to trigger the segmentation fault. I know that it was just a small PHP file, so nothing special though.
Hum I just hit something that looks awfully similar after updating master, but that was with a local PHP file. Maybe it's a bug that has nothing to do with SFTP but with an update to PHP handling, I'll try and see what's up…
I believe it's probably a bug in the HTML parser introduced in the CTags sync from baaed02db0c345da0034d7f87fa3aa8c2f55b753. Looks like parsing the embedded PHP has some bugs.
OK it's actually the PHP lexer, but the HTML one seems to have similar issues. Either way, they apparently report offsets past the end of the file when they embed other scripting languages, leading to issues. I guess some extra checks should happen before ending up OOM, but the offsets should be fixed in the first place. I'll try and debug that when I have time, right now I just need my work tool to start working again :D
See https://github.com/universal-ctags/ctags/pull/4097, it *should* fix it.
Thanks!
github-comments@lists.geany.org