View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0027003||Lazarus||IDE||public||2014-11-06 09:10||2018-07-17 00:09|
|Reporter||tiger||Assigned To||Martin Friebe|
|Product Version||1.0.5 (SVN)||Product Build|
|Target Version||1.4||Fixed in Version||1.5 (SVN)|
|Summary||0027003: False debug running condition prevents shutdown|
|Description||When a pascal program is build using IDE, the IDE indicates it is running and displays an error prompting to stop debugger to rebuild. |
The "stop" item on the run menu is always enabled ( and apparently does not reset the run condition ).
This also prevents shutting down the IDE since that also throws a dialogue box and which ever option is selected it fails to close and similarly does not reset the run condition.
|Steps To Reproduce||1 open a pascal program file in IDE|
2 build ( not run )
3 build again
|Additional Information||I did not see this on a previous distro running 0.98 but that is not longer functional to compare now. |
|Tags||No tags attached.|
|Fixed in Revision||47377|
||Is the Product Version correct? It is old, please test with trunk.|
Sorry, eye problems ;) it's 1.0.8 not 1.0.5; current Fedora issue:
Package lazarus-1.0.8-4.fc20.i686 already installed and latest version
Is this "minor" ?
Not being able to close Lazarus without using kill -9 and not knowing whether there is a debug session running or not and not being able to stop it, sounds like a major drawback for an IDE.
AH, I've found what causes the error condition. It's not the build as reported initially, it's F9.
I tested as reported and just the build does not trigger the error.
F9 'run' shows an error dlg about not being able to find the xterm window , after that impossible to run again because it says it's running and Stop does not work, etc....
ps -ax does not seem to show any process running, so this appears to be some internal flag which is getting set despite the process terminating.
This also implies some defective error checking in the run|stop command since it fails to stop since it was never there but "stop" is still enabled.
Any 1.0.x is outdated. Besides the latest 1.0x is 1.0.14 which had many fixes to the debugger. Though I do not know if your issue was addressed, and there are not going to be any more 1.0.x fixes.
The current version is 1.2.6.
If Fedora does not ship this, then this is an issue for the Fedora maintainers. We have no influence what Fedora ships.
I recommend to try installing the latest from the packages we provide at Sourceforge or our mirrors.
** ONLY 1.2.6: **
If the issue persists with 1.2.6 then please report with the results of the below. And supply a log http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session for a debug run where the issue did happen.
** ONLY 1.0.x: **
You may try the below, but no fix will be added to the 1.0.x series, so reporting back is optional.
If the issue persists, or you want to find a workaround for your current version:
Please check what is in your "Run" > "Run Parameters" : "Host Application"
If it is not empty, please set it to empty.
If you debug a console app, please use "View" > "Debug Windows" > Console or terminal
2) Check your setup: http://wiki.lazarus.freepascal.org/Debugger_Setup
3) If the condition happens, try using "Run" > "Reset Debugger"
If that helps, you can try in the global options under debugger, setting the checkbox "Reset after each Run".
Thanks for the suggestions. Fedora never aims to be bleeding edge. That can cut both ways. The main advantage is supposed to be that it's all well tested and rock solid. That looks like a myth which is in the process of evaporation.
If these are now unsupported versions I could try bugging them to update what they ship. Could you provide a link that would show 1.0.x is no longer supported by the project?
I'm used to working on Gentoo where you can do pretty much what you want but that freedom has a heavy maintenance overhead. I'm still in the process of setting up this Fedora installation.
The 'can't stop' situation seems to be the same as reported here, also Fed20:
In fact the whole GDB situation with dwarfs and stabs version breakage etc make this look like a huge time expenditure just to get a debugging environment working.
I recall looking at fpc/laz about 8 years ago and concluding that fpc looked pretty good, but Lazarus had a long way to go. Check back in 5 years....
I'm a little late with 5y, but the first impressions are not too encouraging. Maybe Fedora need a kick up the rear on this.
Is this kind of problem specific to Lazarus/gdb interactions or are there problems using gdb with fpc in any context?
I managed to get 1.0.14 by enabling updates-testing repo.
Since Fedora have quite a structured and methodical test reporting system to move stuff from testing to updates, guess this just indicates either test results are not good ( things like gdb not working and crashing would be a downer ) or that very few test and report using Lazarus on Fedora so they never get enough input to trigger approval.
Answered on forum, as it is not directly related to fixing the bug (if still present in current version
did "View" > "Debug Windows" > terminal output
run parameters is and was empty.
The exact msg on hitting F9 is:
"Exception while creating process: Could not detect X-Terminal program"
This and the bug remains as before in 1.0.14
There's a recent bug already open requesting 1.2.x
Hopefully that will trigger some action.
I see. This may be an fpc issue. fpc may need a terminal to launch gdb in the may requested by the IDE.
I will have to ask some of the other developers.
Can you try to run fpc outside the IDE, and see which version it does report?
Can you report the output of "env" on a shell (or whatever prints your environment?
Do you have any of the following terminals?
'konsole' (kde only)
'gnome-terminal' (gnome only)
And if so, are the in a location that is in your search path (env PATH)?
Also what desktop and windowmanager do you use?
This bug consists of 2 issues
1) detecting of a terminal on your system in fpc. This needs the attention of the fpc team. An 2nd bug may be forked for this at some time.
For this 1st part please answer the questions from my last note. Also someone from the fpc team may ask further questions.
2) handling of the error in the IDE. If the debugger can not be started this should give an appropriate error, rather than ending in an invalid state.
This 2nd part is for my attention.
> F9 'run' shows an error dlg about not being able to find the xterm window
Please install xterm. See also the related issues.
Juha, thanks, that is a work around. Installing xterm removes the error condition that causes the bug to happen.
Martin, this was tested on Fed20 LXDE "spin" which provides lxterminal terminal emulator.
Free Pascal Compiler version 2.6.2 [2013/08/08] for i386
I agree with your 2), this error condition appears to be detected in that it displays a messages but is not handled correctly.
My guess is that it was never tested on the real error condition but the message box added 'just in case'. It is presumably fairly simple to prevent Lazarus getting into a messy, unusable state where it has to be killed.
To judge from the behaviour, it seems it is relying on some internal flag being set to know whether the process is running or not. This is not getting cleared when the process fails to be created ( in this case because of missing xterm ). Perhaps a more direct check on the process would be better in at least some situations ( like user "stop" or IDE prompting user whether to stop or not ).
This leads me to think that if something else killed the process, Lazarus would end up in an equally confused situation where it can't do anything because it wants to stop the process first but the process does not exist for whatever reason.
For example, it can never exit since it prompts the user to kill the debug session, then fails but does not clear the run condition. This may be valid in some cases but not if the process does not exist. It seems there are a couple of bugs here in the IDE. Over reliance on the state of binary flag that never gets checked even when stop fails, and general error trapping that is not peculating high enough in the call stack.
It also appears that some error trapping code has been added but never actually tested with a real error condition.
It would be nice if this could be tightened up a bit independent of the xterm problem that brought it to light.
A later kill of gdb should not be a problem. The IDE handles for example, if GDB crashes and disappears.
Also "reset the debugger" was improved at some time. So I would expect that in 1.2, if you choose "reset the debugger" it stands a very good chance to recover. Though I have not tested it on this particular case.
Please test and close if ok.
The error did not occur directly in the gdb launching code. That already had a check for error.
When I reproduced, I did however get a crash in the code reacting to the error condition. This left the debugger unresponsive as described.
This is now fixed.
It is likely that this is the same that happened for you. If not, and if the issue persists please reopen.
|2014-11-06 09:10||tiger||New Issue|
|2014-11-06 09:20||Juha Manninen||Note Added: 0078936|
|2014-11-06 10:00||tiger||Note Added: 0078938|
|2014-11-06 10:07||tiger||Note Added: 0078942|
|2014-11-06 10:17||tiger||Note Added: 0078944|
|2014-11-06 10:47||Martin Friebe||Note Added: 0078948|
|2014-11-06 10:47||Martin Friebe||LazTarget||=> -|
|2014-11-06 10:47||Martin Friebe||Status||new => feedback|
|2014-11-06 10:49||Martin Friebe||Note Edited: 0078948||View Revisions|
|2014-11-08 18:14||tiger||Note Added: 0079016|
|2014-11-08 18:14||tiger||Status||feedback => new|
|2014-11-08 19:10||tiger||Note Added: 0079017|
|2014-11-08 19:15||Martin Friebe||Note Added: 0079018|
|2014-11-08 19:20||tiger||Note Added: 0079020|
|2014-11-08 21:00||tiger||Note Added: 0079021|
|2014-11-08 21:06||Martin Friebe||Note Added: 0079022|
|2014-11-08 21:15||Martin Friebe||Note Added: 0079023|
|2014-11-08 21:15||Martin Friebe||Assigned To||=> Martin Friebe|
|2014-11-08 21:15||Martin Friebe||Status||new => confirmed|
|2014-11-09 09:37||Juha Manninen||Relationship added||related to 0007867|
|2014-11-09 09:39||Juha Manninen||Relationship added||related to 0019708|
|2014-11-09 09:44||Juha Manninen||Note Added: 0079036|
|2014-11-09 13:34||tiger||Note Added: 0079041|
|2014-11-09 13:41||tiger||Note Edited: 0079041||View Revisions|
|2014-11-09 15:54||Martin Friebe||Note Added: 0079044|
|2015-01-14 02:19||Martin Friebe||Fixed in Revision||=> 47377|
|2015-01-14 02:19||Martin Friebe||LazTarget||- => 1.4|
|2015-01-14 02:19||Martin Friebe||Note Added: 0080368|
|2015-01-14 02:19||Martin Friebe||Status||confirmed => resolved|
|2015-01-14 02:19||Martin Friebe||Fixed in Version||=> 1.5 (SVN)|
|2015-01-14 02:19||Martin Friebe||Resolution||open => fixed|
|2015-01-14 02:19||Martin Friebe||Target Version||=> 1.4|