terminal persistence after crash #2703
Comments
|
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 |
|
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 occurences.
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.
|
|
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 occurance, 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.
|
|
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 |
|
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:
a) there is a programmed delay of perhaps half a second before returning to the event loop 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.
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 😁) 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.
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.
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 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.
Then you are not spawning 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.
This contradicts your statement above, does the terminal application run multiple processes or one process with multiple windows?
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.
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.
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.
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
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.
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.
Thank you for volunteering.
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 The good news: I've figured this out. See: #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: #2708 Resolving #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. |
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.
27 December 2020: this workaround is incorrect:
see: #2708
for a complete explanation and resolution for this bug.
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.
The text was updated successfully, but these errors were encountered: