23 December 2020 Noon
geany version: 1.32 ubuntu version: 18.04
Lately I've been running my machine until it shuts off from a drained battery.
Today I noticed that when I run python programs using the toolbar execute button, the icon does not change back to a gear from the circle-slash when the program finishes.
The practical effect of this is you have to click the button again to get the gear icon, but the terminal closes instead of remaining open. This is very inconvenient since it makes it impossible to compare outputs from two different versions side by side.
**Workaround**
I solved the problem by opening the "set build commands" dialog and changing the execute command to something that throws an error, e.g. python "%p%f" (no '/' between), running something, and then changing the execute command back to its original value. (python "%f")
Evidently, geany stores some state that is not reset owing to the crash, and in some cases is not sanitized on startup.
When you say the laptop "shuts down" do you actually mean shutdown, or hibernate or suspend?
If the Geany execute command item is activated while a command is running it terminates the command, this allows programs that get into an infinite loop to be terminated. When running in a terminal Geany does not know the process ID of the program, only of the terminal, so that is what is terminated, and hopefully it will terminate the program. Similarly as it does not know the program process id there is no way Geany can find out if the program has finished, only if the terminal has finished, so the execute action remains as "stop" until the terminal closes. So this part is working as intended.
Geany does not store any execute state when it closes because it no longer owns the terminal process when its restarted (if that process still existed) so there is no point in it doing so. I suspect that if the execute icon stays at stop then your laptop is not shutting down, it is hibernating or suspending, so Geany is restored in its previous state, but I have no idea if the terminal process termination is correctly delivered in that case, possibly not, but its not a scenario Geany has been designed to cope with, YMMV.
If you want to have multiple terminals open the command Geany runs (from `Preferences->Tools->Terminal`) must complete. I havn't tried it, but you could try modifying that preference to run the terminal in a shell and detaching it.
24 December 2020 1:15 PM
I mean the power management system determines that the battery can no longer sustain
operation and the machine abruptly shuts off, without notice, and without any regularized
software shutdown.
The linux battery indicator shows 0% with estimated time ranging from a few minutes to
20 minutes prior to shutdown. I am doing this because the battery indicator rarely manages
to show 100% even though the available use time is consistent with a fully charged battery.
My goal is to ascertain whether there is a bug in the BIOS or the battery indicator by tracking
the variation in behavior over multiple occurances.
The geany issue report is collateral to my primary purpose (accidental, and not consistent
across shutdowns).
Following shutdown the machine will not turn on save for blinking the power button light
when it is pressed. I therefore must stop working until I find a power outlet.
In summary, the shutdown is uncontrolled and so it is appropriate to call it a crash.
John Hull
John_Hull@mail.com
Sent: Wednesday, December 23, 2020 at 1:06 PM From: "elextr" notifications@github.com To: "geany/geany" geany@noreply.github.com Cc: "ruminations" John_Hull@mail.com, "Author" author@noreply.github.com Subject: Re: [geany/geany] terminal persistence after crash (#2703)
When you say the laptop "shuts down" do you actually mean shutdown, or hibernate or suspend?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
24 December 2020 2:00 PM
First, thanks for the info about geany internals.
I've been using geany for years and having multiple execution terminals simultaneously open
is part of my standard workflow. It came as a complete surprise that yesterday it would not allow
me to do that. I remembered that the previous day I had been working in geany when the
powerfail happened, so I began playing with the settings until geany started to behave again.
I tried various things, like putting in the complete path to the python binary. What worked was
when I made a mistake and the execute failed with an error.
From my 'geany.conf':
[tools] terminal_cmd=x-terminal-emulator -e "env PYTHONPATH=/usr/local/lib/python2.7/site-packages /bin/sh %c" browser_cmd=sensible-browser grep_cmd=grep
Which is standard except for the PYTHONPATH adjustment which points geany to my personal library.
I added that after I discovered that the addendum to my '.bashrc':
# 20201017 enable using my personal packages export PYTHONPATH="/usr/local/lib/python2.7/site-packages"
was ineffective from within geany, probably because 'sh' symlinks to some simpler shell. Beyond
that, all configurations are from a standard ubuntu repository installation that was performed a few
days before the bash and geany configuration alterations.
I notice now that the build command is the unaltered default:
python "%f"
and that differs from the 'geany.conf' file, but that should not matter since the build
command becomes the %c in the config file.
Running just now a program that has a lengthy test suite, I see that the execute icon changes
from a gear to the circle slash and changes back almost immediately to the gear icon, where
the test suite is still running as I type this, and has now stopped. I have no difficulty starting
other executions, even before the lengthy test completes, and all terminals remain open until
I explicitly close them, as I expect should happen.
That is to say, everything is working fine now, as it was yesterday after I caused the execute
command to throw an error and then restored the default.
The reason I mention this is that your paragraph on the icon behavior does not match my
experience, either over the past years or now. Moreover, if I run the lengthy test suite and
immediately run the same test suite by clicking the immediately restored gear, I get a new
independent terminal instance and the first invocation does *not* terminate, but continues,
as I would expect it to do. If I need to terminate the process, I can use ^C or simply close
the terminal window, so this experience also does not match your paragraph.
Finally looking in the task manager, I see geany is the parent of the terminal and the
terminal is the parent of a shell which is the parent of the lengthy test, as expected.
If I suspend by closing the laptop in the middle of the lengthy test, and then reopen
the laptop and touch the power button to resume, the situation remains, as expected.
When the program stops, its process disappears, and the shell and the terminal remain
as expected. When I close the terminal by whatever method, both the shell process
and the terminal process disappear, as expected.
In closing, I realize that the issue I reported is one of the most difficult kinds to track
down, and it is not likely to affect many people. It is, however, real. I did in fact
spend an hour of my time yesterday trying to resolve it. The workaround I discovered
is effective, and given the rarity of occurence, I certainly don't expect any concerted
effort to resolve it. It should, however, remain in the back of your mind, especially
when you happen to be working on the geany initialization code, or perhaps gui
interactions with the os window manager.
I should point out that I am using Bodhi linux (5.1.0) which uses a variant of the
enlightenment libraries. These are peculiar libraries, and you either love them or
hate them, and they do have some quirks. The problem may be some bizarre
interaction between your gui libraries (presumably still gtk, for I chose geany
specifically because it uses gtk) and the enlightenment libraries, even if there
really is no temporary state storage in geany.
Sincerely
John_Hull
John_Hull@mail.com
Sent: Wednesday, December 23, 2020 at 5:56 PM From: "elextr" notifications@github.com To: "geany/geany" geany@noreply.github.com Cc: "ruminations" John_Hull@mail.com, "Author" author@noreply.github.com Subject: Re: [geany/geany] terminal persistence after crash (#2703)
If the Geany execute command item is activated while a command is running it terminates the command, this allows programs that get into an infinite loop to be terminated. When running in a terminal Geany does not know the process ID of the program, only of the terminal, so that is what is terminated, and hopefully it will terminate the program. Similarly as it does not know the program process id there is no way Geany can find out if the program has finished, only if the terminal has finished, so the execute action remains as "stop" until the terminal closes. So this part is working as intended.
Geany does not store any execute state when it closes because it no longer owns the terminal process when its restarted (if that process still existed) so there is no point in it doing so. I suspect that if the execute icon stays at stop then your laptop is not shutting down, it is hibernating or suspending, so Geany is restored in its previous state, but I have no idea if the terminal process termination is correctly delivered in that case, possibly not, but its not a scenario Geany has been designed to cope with, YMMV.
If you want to have multiple terminals open the command Geany runs (from Preferences->Tools->Terminal) must complete. I havn't tried it, but you could try modifying that preference to run the terminal in a shell and detaching it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Well as I said, Geany does NOT store anything about running subprocess state, and even if it did nothing gets stored if its crashed. Thats why I am suspecting that your laptop is suspending or hibernating when its battery goes flat, which may store Geany's in memory process state and restore it hence getting the same menu state. I note that suspending works as advertised in your experiment, if you still have battery, but maybe its not so reliable if the battery dies. But Geany has no knowledge of suspension and resumption, so its nothing it caters for, its entirely up to your OS and desktop if it works and Hiesenbugs are common in Linux suspend/hibernate/resume IIUC.
The menu behaviour is as it was intended since 0.19 (IIRC) but its possible that in the past there was a bug in the process spawning code that returned the menu immediately, but the spawning code was mostly re-written at some point since then, possibly removing the "unintended feature". This change in behaviour has been pointed out before, but AFAIK no conclusion was reached as to why it happened, but as I said its now working as intended. Did you try running the terminal from a shell and detaching it to allow multiple terminals?
Your environment problem is most likely because you do not start Geany from a shell (maybe a menu or shortcut). In that case nothing reads your shell startup files to set PYTHONPATH so Geany does not inherit it. Changing the menu/shortcut command to run Geany from a shell should fix that. Tell your distro packagers to fix the menu/shortcut, Geany does not make that. Alternatively your distro may have aliased `sh` to `dash` not `bash` so again the startup file is not read.
25 December 2020 Noon
First of all, the sub-process state is irrelevant as is suspension and hibernation. What is relevant is the state of the geany user interface, and surely there is state storage of that if only in RAM.
Second of all, I am talking about a **complete power failure**, intentionally induced. This is not suspension or hibernation. It is the same thing that would happen if you pulled out the battery while your machine is running only on the battery. The only remedy is a cold reboot with wall power, and that is my underlying intention. In fact, when I do reboot, it is very clear it is a **cold reboot**. I am not naive or a noob. I understand these systems down to the device level, and have programmed them at the device level. I know the difference between these various power states very well.
Thirdly, I do not understand the meaning of your second paragraph, but if I infer correctly, you are reasserting the incorrect idea that the circle slash persists during execution during normal behavior and the x-terminal can be killed by clicking. Manifestly, empirically, this is **not** the case, and never has been in my experience, at least with python code which is all I use geany for. The only way to kill an execution is with ^C, closing the window, or any key entry after the sub-sub-process has finished, which closes the window. If it is the developer's intention that the gear icon **not** be restored immediately (after the x-terminal spawn), that in my view is a bad design choice and is actually a deal breaker for me using your software, should your software actually change to behave that way. Once again, it currently does **not**. It would be an utterly useless feature to kill a sub-process with an icon click. The existing mechanisms are perfectly fine.
To be clear, the circle slash appears to be only briefly visible during x-terminal spawning (an X-window application **not** a shell), which itself spawns a shell which spawns the actual program being executed. There are **three** processes spawned. These three processes are clearly visible in the task manager. If there is already an x-terminal instance running somewhere else, only the shell and the actual program processes are spawned. This is **empirical** observation and is indisputable.
FourthIy, running multiple x-terminals is **not** a problem. That is normal behavior and it is still normal behavior after I fixed the issue with my workaround. I'm not going to waste time detaching shells when I have the behavior I want already, which is the behavior geany has **always** exhibited, and the fix persists across geany restarts.
Finally, my "environment problem" is not a problem. I merely explained why my geany.conf is slightly different from the default. To be complete, I ran 'which sh' and get /bin/sh, which is perfectly fine with me (not a problem), and perfectly explains why I needed to alter geany.conf, which again, is **not a problem**. In fact, it is preferable to be using a lightweight shell in this context, so the distro packagers made a good design choice.
The geany failure I discovered was accidentally discovered and is **very real**.
Now with that out of the way, let us proceed rationally.
I am now making sure every night, when I force a power failure, that I am using geany and nothing else.
I can tell you this:
1) The problem occurs when I run a program and the power surge from that action forces the battery burn down over the edge. The machine shuts off immediately.
2) Since I ran a program, the geany user interface has momentarily changed the icon to the circle slash at the moment of power failure.
3) Since the circle slash is momentarily visible in any normal case, at least one of three things must be happening:
a) there is a programmed delay of perhaps half a second before returning to the event loop b) geany is noting the user interface state change to a disk file, which takes a little time c) the process spawning is not as fast as it might be for some reason
I do not know which is true, but at least one **must** be true, for otherwise the circle slash would never be visible in the user interface, because even the slowest decade old machine is truly very fast.
4) Any of those three possibilities is interrupted by the power fail, possibly signaled to geany by a kernel signal, but with little or no time to do anything about it.
5) After coming up cold, geany clearly loads state information from geany.conf, and doubtless sets various internal defaults. All complex programs do that. It is common enough that the complexity obscures some of this and some state settings are overlooked, either because they are not in the .conf file or because they are overlooked due to the myriad other concerns that a programmer has to deal with. Mistakes happen. That is reality.
5) The bad behavior is not remedied by closing geany and restarting it. That is the first thing I tried. There is therefore some user interface state setting somewhere that is reloaded.
6) The bad behavior is remedied by twiddling with the execute command in the Set Build Commands dialog.
7) My memory of the sequence of events leading to realization that I had a remedy is muddied, but it is clear that it results from the sequence of programmed actions executed either by clicking 'OK' in the build settings dialog, or by the error processing events that occur when when the gear icon is clicked and the build settings execute command is faulty. This greatly limits the code blocks that need to be examined to determine what user interface state setting is being missed during startup. Those two code blocks are changing settings, one because of a user request. The error processing is not necessarily altering settings, but it certainly might be, and that would seem logical - when you encounter a fault, you usually want to flag it. If so, it may not be the flagging that remedies, but the existence of the flag when the build settings are next saved with 'OK'.
8) By examining those code blocks you can quickly determine what to look for in the startup code and remedy the problem.
All of this is assuming geany is well designed, and I think it is.
In the meantime, I will continue to burn my battery down every night, and at some point, I will reproduce the error, pay closer attention to the remedy sequence, and report it here.
First of all, Geany is a totally volunteer project, people work on it in their own time, and cover a wide spectrum of knowledge and experience. I am likely older and have more coding experience than you (and I like to think capable of being grumpier than most :grin:) so there is no need for reports that appear to be rants with bolded text demanding people do things. Volunteer projects don't work that way, it just turns people off helping you.
First of all, the sub-process state is irrelevant as is suspension and hibernation. What is relevant is the state of the geany user interface, and surely there is state storage of that if only in RAM.
Of course, but this is irrelevant if Geany is closed and restarted, the value is reset, it is not stored and restored. Since you "know these systems very well" you will therefore know that any state in memory is not restored when a process is closed and started again unless the program stores it and reloads it. Since Geany does not store and reload it the only reasonable solution I can think of at the moment is that it was being restored from hibernation.
Thirdly, I do not understand the meaning of your second paragraph, but if I infer correctly, you are reasserting the incorrect idea that the circle slash persists during execution during normal behavior and the x-terminal can be killed by clicking. Manifestly, empirically, this is not the case, and never has been in my experience, at least with python code which is all I use geany for.
WFM, in Geany 1.36 to 1.38 that I have available, if it doesn't work perhaps it was a bug back in 1.32 although I don't remember such a fix. Or whatever terminal you are using has unusual behaviour (see below).
that in my view is a bad design choice and is actually a deal breaker for me using your software
That is of course your personal view and choice, but before you throw your toys out the cot, did you try my suggested workaround, although from your description below it seems the misbehaving terminal application is doing what you want already.
To be clear, the circle slash appears to be only briefly visible during x-terminal spawning (an X-window application not a shell), which itself spawns a shell which spawns the actual program being executed. There are three processes spawned. These three processes are clearly visible in the task manager. If there is already an x-terminal instance running somewhere else, only the shell and the actual program processes are spawned. This is empirical observation and is indisputable.
Then you are not spawning `xterm`, which is the default Geany setting, but some other terminal window application, which is combining multiple invocations into one detached process instead of running separate processes. So this is why it returns immediately to Geany and the icon changes back.
This is information that has been missing from your previous descriptions, although you still havn't actually named which terminal application it is running. Remember I can't see your machine, I don't know anything about it except what you tell me.
FourthIy, running multiple x-terminals is not a problem. That is normal behavior and it is still normal behavior after I fixed the issue with my workaround.
This contradicts your statement above, does the terminal application run multiple processes or one process with multiple windows?
I'm not going to waste time detaching shells when I have the behavior I want already, which is the behavior geany has always exhibited, and the fix persists across geany restarts.
So clearly didn't try the workaround, nor (from your description of "waste time detaching shells") even understood it, but clearly the errant behaviour of your terminal application is suitable for you, so that means Geany can keep the behaviour it has always had, and you are also "happy". But it does mean you have a non-standard setup and need to provide additional information when reporting problems.
So having dealt with several rabbit holes, back to the original problem.
Second of all, I am talking about a complete power failure, intentionally induced. This is not suspension or hibernation.
My Linux laptop automatically hibernates if the battery gets low before it shuts down, and since Geany does _not_ store and restore execute icon state, I therefore look for alternatives that can restore state, such as a hibernate.
Since the circle slash is momentarily visible in any normal case, at least one of three things must be happening:
a) there is a programmed delay of perhaps half a second before returning to the event loop b) geany is noting the user interface state change to a disk file, which takes a little time c) the process spawning is not as fast as it might be for some reason
and the likely answer is:
d) the icon is changed at the initial activation and cleared after the terminal application has spawned and created its window and started a shell and started Python, and reported its terminated even if it isn't, all of which will cause a delay and steal cpu cycles from Geany and the X server that does the displaying of the icon and add to the poll loops that exist (IIUC) in the GTK/Glib toolkit communication with the X server and the signal handlers. So the icon being visible for a short time is pretty likely without any explicit coding.
After coming up cold, geany clearly loads state information from geany.conf ... Mistakes happen. That is reality.
Yes, which does not include the state of the execute icon, that is initialized with g_new0() which returns cleared memory. Sure everybody makes mistakes, but unless someone manages to point out where the code can avoid starting with the state value 0 then something else is going on (like weird terminal apps above), see `build.c`.
is not remedied by closing geany and restarting it. That is the first thing I tried. There is therefore some user interface state setting somewhere that is reloaded.
I hear you but until either somebody replicates it, or points to the code path (see above) its impossible to know whats happening.
So pending that I am working on the basis that "something else" is happening, however from the information provided its not possible to say what.
remedied by twiddling with the execute command in the Set Build Commands dialog.
Yes if "something" causes the execute state to be out of sync it needs to be "tricked" into changing state since the process its monitoring no longer exists and so its state will never change. Just lucky the code clears the state on an error, even though theoretically its doesn't need to. That does not help finding the cause though.
By examining those code blocks you can quickly determine what to look for in the startup code and remedy the problem.
Thank you for volunteering.
In the meantime, I will continue to burn my battery down every night, and at some point, I will reproduce the error, pay closer attention to the remedy sequence, and report it here.
As noted above, the remedy is understood, its how it gets it out of sync that is interesting and useful. I doubt anyone else is going to flatten their laptop batteries to try to replicate the exact conditions, so yes its only you who will reproduce it. Try to provide as much information as possible when it happens.
27 December 2020 8 PM
The good news:
I've figured this out. See: https://github.com/geany/geany/issues/2708
The bad news:
The bug is completely deterministic and much worse than I thought.
I won't trouble you with the details of false correlations, mis-directions, confusion and frustration that has beset me the past few days.
Suffice it to say that if we hadn't butted heads over our very different experiences with geany, I never would have looked at the things that I needed to look at to resolve the ambiguities.
Long story short: we are both right.
You are correct that geany is designed for single execution.
I am correct that all I have ever experienced is a wonderful development environment for multiple simultaneous processes.
I am now closing this issue, which is only useful in the sense that it led to clear understanding as expressed in: https://github.com/geany/geany/issues/2708
Resolving https://github.com/geany/geany/issues/2708 is up to you and the geany developers. I can only hope you take heed of my concluding remarks. As of now, I wash my hands of this and return to my other tasks, since I now have a deterministic understanding of how to control the anomalous behavior of geany that actually is not anomalous, but only very complicated.
Closed #2703.
github-comments@lists.geany.org