View Issue Details

IDProjectCategoryView StatusLast Update
0027003LazarusIDEpublic2018-07-17 00:09
ReportertigerAssigned ToMartin Friebe 
Status resolvedResolutionfixed 
Platformx86OSlinuxOS Versionfedora20
Product Version1.0.5 (SVN)Product Build 
Target Version1.4Fixed in Version1.5 (SVN) 
Summary0027003: False debug running condition prevents shutdown
DescriptionWhen a pascal program is build using IDE, the IDE indicates it is running and displays an error prompting to stop debugger to rebuild.

"stop debugging"

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 Reproduce1 open a pascal program file in IDE
2 build ( not run )
3 build again
Additional InformationI did not see this on a previous distro running 0.98 but that is not longer functional to compare now.
TagsNo tags attached.
Fixed in Revision47377
Attached Files


related to 0007867 assignedMarc Weustink Debugger can not use xterm as starter applicaion 
related to 0019708 resolvedMartin Friebe Lazarus under linux requires xterm 


Juha Manninen

2014-11-06 09:20

developer   ~0078936

Is the Product Version correct? It is old, please test with trunk.


2014-11-06 10:00

reporter   ~0078938

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


2014-11-06 10:07

reporter   ~0078942

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.


2014-11-06 10:17

reporter   ~0078944

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.

Martin Friebe

2014-11-06 10:47

manager   ~0078948

Last edited: 2014-11-06 10:49

View 2 revisions

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 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:

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".


2014-11-08 18:14

reporter   ~0079016

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:,20756.msg120842.html#msg120842

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?



2014-11-08 19:10

reporter   ~0079017

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.

Martin Friebe

2014-11-08 19:15

manager   ~0079018

Answered on forum, as it is not directly related to fixing the bug (if still present in current version


2014-11-08 19:20

reporter   ~0079020

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


2014-11-08 21:00

reporter   ~0079021

There's a recent bug already open requesting 1.2.x

Hopefully that will trigger some action.

Martin Friebe

2014-11-08 21:06

manager   ~0079022

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?

Martin Friebe

2014-11-08 21:15

manager   ~0079023

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.

Juha Manninen

2014-11-09 09:44

developer   ~0079036

> F9 'run' shows an error dlg about not being able to find the xterm window

Please install xterm. See also the related issues.


2014-11-09 13:34

reporter   ~0079041

Last edited: 2014-11-09 13:41

View 2 revisions

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.

fpc -v
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.

Martin Friebe

2014-11-09 15:54

manager   ~0079044

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.

Martin Friebe

2015-01-14 02:19

manager   ~0080368

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.

Issue History

Date Modified Username Field Change
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