I am having a very strange and frustrating experience with lazarus, in my fpGUI app.

When running, after pressing a button in my app which calls a process, the app seems to freeze up. It just sits there, unresponsive. My program has no breakpoints in it.

The only way I can get it to move is by *adding* a breakpoint, somewhere within the code that it is waiting to execute. Then it stops at that breakpoint. I can remove the breakpoint, tell it to run, and it continues on its merry way.

If my program *does* have breakpoints in it, it will not get to them. Lazarus seems to need to have a breakpoint *added* into the code, *during* the run, before it will proceed.

I'm only seeing this with one project. Within that project it is intermittent.

Has anyone else seen anything like this? I guess I'd better report it on mantis...

version 0.9.29-0-20101231, from debian packages on freepascal.hu i386-linux-gtk 2

Cheers,
David

You mean your app forks a new process (or executes another app as new process)?

The only way I can get it to move is by *adding* a breakpoint, somewhere within the code that it is waiting to execute. Then it stops at that breakpoint. I can remove the breakpoint, tell it to run, and it continues on its merry way.

very strange...

If my program *does* have breakpoints in it, it will not get to them. Lazarus seems to need to have a breakpoint *added* into the code, *during* the run, before it will proceed.

version of gdb?

You should at least attach the output of the "debug output" window (from "view" / "debug windows")

Also open the breakpoint window and check there is no other breakpoint (even so, if there was, and if it was hit, it should stop there)

Also start Lazarus from console, and watch for any output of the IDE. It may report something there....

32 or 64 bit? or maybe a mix? 64 bit system, but running 32bit apps?

Martin

Op 2011-01-06 22:51, David Emerson het geskryf:

Has anyone else seen anything like this?

Yes I have. I have noticed something like that too... when my apps run via the IDE (which I hardly ever do anymore) they break for no reason.

I have looked into it (at the time), and it seems that if you set a breakpoint in the IDE and save the project. Then modify your code so the line at which the breakpoint was, is not source code any more (eg: a blank line or a comment), the app still breaks at a point close to the original breakpoint, but the IDE doesn't show it as a breakpoint (no red dot, and not breakpoint listing in the breakpoints window).

I had to delete the breakpoint entry in the XML stored in that projects info file manually to resolve the problem. As I said, this was with Lazarus dated 2010-11-09. I haven't tried to reproduce with a newer version yet.

Regards,
- Graeme -

Thanks a lot for the tip, Graeme.

Martin: I'm planning to look into it when I get back to that project where the error is occurring. Thanks for your help as well!

Cheers,
David

Hello Lazarus-List,

Friday, January 7, 2011, 7:54:17 AM, you wrote:

GG> I have looked into it (at the time), and it seems that if you set a GG> breakpoint in the IDE and save the project. Then modify your code so the GG> line at which the breakpoint was, is not source code any more (eg: a blank GG> line or a comment), the app still breaks at a point close to the original GG> breakpoint, but the IDE doesn't show it as a breakpoint (no red dot, and GG> not breakpoint listing in the breakpoints window).

In my case the reason is that the code where the real breakpoint is located has been removed by the linker (non called code) so gdb sets the breakpoint in the next valid source code line, while editor keeps the original line for the breakpoint position.

Sounds like you had smart linking enabled. As a rule of thumb you should have no optimizations enabled when debugging: optimization level 0 or 1 and most importantly no smart linking.

True, the IDE remembers LineNumber and FileName, and sets the Breakpoint at this point (and shows it at this line). You can set a breakpoint anywhere (if the app has not yet been started)
GDB applies this breakpoint to the next line of code, so it will stop there.

You can use the breakpoint-list window, to find them.

The problem with testing the validly of such a breakpoint are:
- You can not check the loaded source. It may differ from the compiled source (It may have been changed after compilation(
- The line info from the debug info can be used (blue dots), but:
- it takes a long time to load => if you have a lot of breakpoint, start up of the project in the debugger would be real slowed down
- It may not even be available, if the breakpoint is in a library, it only becomes avail, if the library is loaded (gdb (in recent version) will set the breakpoint then)

Only thing, I can think of is that once the breakpoint is hit, and the file is loaded, it could be checked (since then the info should be avail), and then it could pop up an info dialog...

---------
The original reporter said the app just seems to hang. If a breakpoint was hit, you would see the execution mark (green arrow), and you could hit F9 to continue.
So I am not sure if the original poster encountered this same issue

-----
An other issue is that if you open 2 independent copies of the same file (via different sym links) you may be able to irritate the IDE, and the breakpoint may be in the one copy, the execution mark in the other...

Hello Lazarus-List,

Friday, January 7, 2011, 12:52:46 PM, you wrote:

AS> Sounds like you had smart linking enabled. As a rule of thumb you AS> should have no optimizations enabled when debugging: optimization level AS> 0 or 1 and most importantly no smart linking.

No, I do not have any kind of smartlinking active and my debug level are always 1 or in some programs 0, never 2 or upper.

Maybe is the compiler which "removes" the code and not the linker (I'm working mostly in Windows). But for sure if the code is not called anywhere and you put a breakpoint there the next executable line will stop the code, 99% of times a function/procedure entry.

Ah! another hint, in that cases the breakpoint does not change to invalid breakpoint when run.

2011/1/7 Jos? Mejuto :

By default smartlinking is enabled on windows.

Vincent

Op 2011-01-07 14:26, Vincent Snijders het geskryf:

By default smartlinking is enabled on windows.

That's not too clever for a software development tool - especially if it screws with the debugger (which you will use while writing software). Maybe Lazarus should default to disabling that.

Regards,
- Graeme -

No, there is a reason for doing this. If you don't, then all entry points as defined in the windows unit must be present in the DLLs on your system. Since the actual entry points can vary rather a lot depending on the version of windows, it will result in many errors when linking.

Michael.

2011/1/7 Graeme Geldenhuys :

Maybe -CX can/should be disabled, but -XX cannot be disabled, otherwise all external declaration (for example in the windows unit) must be available on the target computer, even if they are not used. I don't know how up to date the windows unit is, but I am not sure it doesn't contain exports only available in vista or windows 7.

Vincent

> By default smartlinking is enabled on windows. That's not too clever for a software development tool - especially if it screws with the debugger (which you will use while writing software). Maybe Lazarus should default to disabling that.

I am a bit astonished to read advices like this. What kind of development tool is it that needs such kinds of precautions to debug a program correctly? What else has the programmer to consider? Do I need years of knowledge about the internals of Free Pascal/Lazarus to use it? I feel put back some decades in software develpement.

Jos? Mejuto wrote

Ah! another hint, in that cases the breakpoint does not change to invalid breakpoint when run.

See my other mail. It is not as easy as it sounds.

If there are only one or 2 breakpoints, the time to load the line info for those units can be tolerated. If there are many, and the IDE tries to load all those line infos then people will start complaining that it takes forever to start-up/run a project in the debugger.

But that's not even the reason. Breakpoints can be in libraries, which are not yet loaded. In that case they can not be disabled or you breakpoints would stop to work for libraries... And that sure would cause some complaints.

Yes it would be possible to work around that (the library issue) too. But at some cost....
As I said, it is easy to check your breakpoints via the breakpoint list window...

Imho the most reasonable course of action is to check at the time the breakpoint is hit.
So if the IDE stops at a breakpoint, it should check that the breakpoint actually is at the same place that the debugger stopped. If not it should present the user with a set of reasonable options: ignore, remove, disable or relocate breakpoint....

BTW, I never knew this was an issue, I encountered that many times myself, it never did bother this mails I never saw any complaint (at least none that I could relate to this issue)..,

Martin

Hello Lazarus-List,

Friday, January 7, 2011, 1:44:22 PM, you wrote:

VS> Maybe -CX can/should be disabled, but -XX cannot be disabled, VS> otherwise all external declaration (for example in the windows unit) VS> must be available on the target computer, even if they are not used. VS> I don't know how up to date the windows unit is, but I am not sure it VS> doesn't contain exports only available in vista or windows 7.

This are my settings in one project under Windows XP SP3:

-MObjFPC -Scghi -Cirot -O1 -g -gl -gh -WG -vewnhi -l -FiF:\Sources\own\SODO\lib\i386-win32 -Fusynapse
-FuF:\Sources\own\virtualmedia\package\lib\i386-win32 -FuF:\Sources\own\varios\streams\lib\i386-win32
-FuF:\Sources\own\components\lib\i386-win32
-FuF:\Lazarus\components\lazcontrols\lib\i386-win32 -FuF:\Lazarus\lcl\units\i386-win32
-FuF:\Lazarus\lcl\units\i386-win32\win32
-FuF:\Lazarus\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -FEoutput\ -osodo.exe -dLCL -dLCLwin32

I can not see any -XX around :-? Same code executes fine under Win7.

Hello Lazarus-List,

Friday, January 7, 2011, 2:04:02 PM, you wrote:

M> Imho the most reasonable course of action is to check at the time the M> breakpoint is hit.
M> So if the IDE stops at a breakpoint, it should check that the breakpoint M> actually is at the same place that the debugger stopped. M> If not it should present the user with a set of reasonable options: M> ignore, remove, disable or relocate breakpoint....

That looks like a quite good solution, at least it will reduce confusion.

M> BTW, I never knew this was an issue, I encountered that many times M> myself, it never did bother this mails I never saw any M> complaint (at least none that I could relate to this issue)..,

I'm not complaining (misspelled?), I was presenting a description of when I get that behaviour and why. First time that happends to me it was a confusion, but after realialized that the breakpoint was in a "dead" code everything becomes clear, not ideal but clear.

Well depends on how you read this.

Every tool has flaws. That is not an excuse for the existing of those flaws in any individual tool (including Lazarus). It just is a fact. For most tools I know (definetlely including Lazarus), the makers (including community) aim to remove those flaws. Until that happens, being given advice how to workaround surely is not bad?

As I stated in my other mail, I don't think this issue was ever pointed out before. And I am highly surprised that it is such big an issue. It never was to me. I actually though of it as a benefit. If by any external edit (svn up) my breakpoint ended up a line above my procedure, it would still work. Very useful.

Anyway now it's known, so one day something may be done.

And yes of course, i would also like to see a debugger specially written and specialized for pascal. That would allow to tackle such issues far better than it ever can be done with gdb. Unfortunately no one has yet given the money that would pay several full time developpers that may be needed to write this....

So until then...

Martin

I'm attaching some debug output. One of the logs was an execution with no breakpoints (view > debug info > breakpoints list is empty; also the lpi file has no breakpoints) and in the other execution I created one breakpoint.

In the execution with no breakpoints, everything went smoothly.

In the execution with the one breakpoint, the program stopped at debug log line 186,
*stopped,reason="breakpoint-hit",bkptno="38", [...] (gdb)

However, when I say the "program stopped", lazarus did not behave as if it had encountered a breakpoint. The lazarus main and source windows did not raise; in the source editor, the line with the breakpoint is marked with a red highlight and checkmark, not with a blue highlight and arrow. Pressing F9 (while focused on the source window) has no effect whatsoever. The call stack window is empty, and the gdb debug output window does not show any stack info, either.

I clicked on the breakpoint line in the source editor, and pressed F5 to remove the breakpoint. The gdb window shows:
<-break-delete 38>
^done
(gdb)

However the program is still not moving.

So at this point, I put the same breakpoint back in. The gdb window shows: <-break-insert -f ab_fpgui_types_unit.inc:230>
^done,bkpt={number="39",type="breakpoint",disp="keep",enabled="y",addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230",times="0"} (gdb)
<-break-enable 39>
^done
(gdb)
<-exec-continue>
^running
(gdb)
*stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",thread-id="1",frame={addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",args=[{name="SENDER",value="0xb76998e0"}, {name="this",value="0xb7861f10"}],file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230"} (gdb)
<-stack-info-depth>
[...] and all the rest.

Martin wrote

You mean your app forks a new process (or executes another app as new process)?

No, it's just a procedure call.

version of gdb?

GNU gdb 6.8-debian

Also start Lazarus from console, and watch for any output of the IDE. It may report something there....

Yes, it does give this interesting output when the program myteriously stops: ERROR: Got NO stop params at all, but was running

32 or 64 bit? or maybe a mix? 64 bit system, but running 32bit apps?

32 everything

An other issue is that if you open 2 independent copies of the same file (via different sym links) you may be able to irritate the IDE, and the breakpoint may be in the one copy, the execution mark in the other...

This *is* extremely annoying, actually -- the IDE often opens up multiple copies of the same (symlinked) source all on its own. Not at all sure why it does this, but it's very irritating. However, in this case, I made sure no copies were open; and even if there were, F9 should resume execution.

I guess I'll report this on Mantis, now that there's presumably enough info to do so.

Any idea how to "clean" my project, so it doesn't do this? Perhaps I just need to create a new project from scratch? Or delete the project.compiled file, or something? I'll play around.

Cheers,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-logs-bp-prob.tgz
Type: application/x-tgz
Size: 10505 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110107/9a797c67/attachment-0001.bin>

Hm, I guess part of the problem is that console output of the application does not work well with gdb. It seems to mix with the gdb output....

From your log:
=====
Databas*stopped,reason="breakpoint-hit",bkptno="38",thread-id="1",frame={addr="0x08073656",func="T_COMMAND_WINDOW__DO_MY_THING_BUTTON_PRESS",args=[{name="SENDER",value="0xb76998e0"},{name="this",value="0xb7861f10"}],file="ab_fpgui_types_unit.inc",fullname="/ab/Pascal/ab_fpgui_types_unit.inc",line="230"} (gdb)

the msgs from gdb goes on the same line, as the app's output. There is nothing the IDE can do, it has no chance of identifying the gdb output, or knowing there was a breakpoint...

see http://bugs.freepascal.org/view.php?id=12172
I haven't looked at this issue further, not sure if there are updates or when there will be. (I know not the news anyone wants to hear; but it seems it's a bug that will take a while to fix / we are unfortunately bound to gdb, there isn't any better solution yet)

Btw: which version of gdb do you use? [edit: found answer] IIRC you are using a very recent Lazarus

I wonder so, the IDE should see the "(gdb)" prompt.... If you start lazarus from a console, can you watch out for an error msg like one of those? [edit: found answer]
ERROR: Got stop params, but did not chnage FTheDebugger.state: ... ERROR: Got NO stop params at all, but was running

You can look for them in gdmidepugger.pp and add code like

    SetDebuggerState(dsPause);

it may prove a workaround for your case, but could break other stuff, and certainly is not the solution....
You can see there is a commented error-state in this place. => problem is there is indeed a valid case where this can happen..... (don't remember details though)

------------------
As for the rest that happens, when you set/unset the breakpoints....

The IDE believes the app is still runing (at least that is the most likely case to be concluded from the details provided)

In order to remove the breakpoint, the IDE does have to send a interrupt (SigInt) to the app, otherwise gdb can not be told to perform anything (the app must pause temporarily)

The IDE should continue "exec-continue" after deleting the breakpoint, strange that it does not. So possible to be explained, because the IDE expects to be in the run command, that would take care => only it is not.....

So somehow the IDE recovers and starts the app

Caused by the earlier attempt to pause the app, while it was actually already halted

Have you tried, if you can F9 after that, and continue?

> version of gdb? GNU gdb 6.8-debian

ah, ok...

ah, ok...

Well it is already on mantis.....

I don't know, but can you somewhere in the "run param" specify an output redirection for your app?
Since you do not seem to need console input, if you could simply redirect all the stuff printed by you app, into a file? then tail the file while you debug....

Not sure if it is possible, just an idea, till something better comes up.

Any idea how to "clean" my project, so it doesn't do this? Perhaps I just need to create a new project from scratch? Or delete the project.compiled file, or something? I'll play around.

the symlinked files may come from old lpi/lps files ... either in project file or in ~/.lazarus/projectsessions
the IDE did have issues creating some invalid pathes, but the ones I knew of have been fixed (but pathes in lpi/lps would remain)

yeah. next time I test this I'll see if I can suppress output.

I did try the run parameter: >logfile
...a basic redirect. And it worked! program output was redirected to the file, and gdb info was seen in the debug output window. Unfortunately, the buffer doesn't get flushed until the program exits, so the usefulness is limited, but certainly better than none, as I had before.

Then I tried to make it a named pipe: mkfifo logfile. The program stalls until something is listening at the other end of the pipe. So "cat logfile" on my terminal allowed the program to continue executing. Unfortunately, the output doesn't come in real time-- even with the named pipe, it seems only to flush after the program exits normally. In fact, if I use ctrl-f2 in lazarus to abort, the buffer is never flushed, and "cat logfile" exits with no output (except I guess an EOF I don't see)

IIRC you are using a very recent Lazarus

0.9.29-0-20101231

> So at this point, I put the same breakpoint back in. The gdb window shows: Have you tried, if you can F9 after that, and continue?

yes, once I remove the breakpoint and put it back in, the program functions more or less normally.

the symlinked files may come from old lpi/lps files ... either in project file or in ~/.lazarus/projectsessions the IDE did have issues creating some invalid pathes, but the ones I knew of have been fixed (but pathes in lpi/lps would remain)

I created a fresh project, and got rid of some old cruft. So we'll see if things work more smoothly from here on out.

As for the breakpoint error, even creating the new project file did not eliminate the problem. After that, I fudged around a bit deleting files here and there, and the problem eventually disappeared. I'll have to get my brother's files again in order to re

Well it is already on mantis.....

the symlink bug or the breakpoint problem?

Thanks so much, Martin
~David.

The breakpoint problem => which basically is due to the apps console output => which is on mantis, the link I included. http://bugs.freepascal.org/view.php?id=12172

The symlink issue, is not stricly debugger related (even so of course it can affect the debugger too)..
I can't tell you to much about it, not my domain of expertise (how lazarus handles those). But I suggest to start a new thread, with appropriate subject to get more people to notice it. => Oh well, yes about symlinks => check your fpc.cfg file too, or package files.
If fpc puts a different path in the exe, than the one the IDE already knows, then the IDE willl learn via gdb of the new path, and boom... => but again, it would have to be in some conf file first.

Martin

Hi Martin,

let's actually try helping the OP, Martin.

Martin, please post the procedure up to the point where the code stops. And under the list where it stops paste the error message from the View / Messages window and some "^^^^^^^" to point to the code. That will help.

Also, try to set a breakpoint one line BEFORE where you have the breakpoint set, as I believe that this is most likely the line where you code is crashing. The press F7 to step into the code and see what is going on. That way you will be able to watch what is really going on.

Good luck and happy debugging. All of this talk about how the debugger works is not helping Martin, who only has one breakpoint set.

Best Regards,
pew,

[snip]

In my opinion, the program crashes then hits the breakpoint, so Martin needs to set the breakpoint a single line of code earlier and press F7.

MSEide uses a pseudoterminal and the gdb "tty" command on Linux.

Martin

Pew wrote

let's actually try helping the OP, Martin.

Hey, that's not necessary, man; Martin is very helpful, and I have solved the problem -- or at least I have a very effective workaround -- thanks to his troubleshooting. In fact I think I'm going to post it as a note to that console output mantis bug.

This is all utterly irrelevant.

Good luck and happy debugging. All of this talk about how the debugger works is not helping Martin, who only has one breakpoint set.

Yes it is. The problem is that the debugger is not working properly!!

The solution is to redirect the program's writeln output, via the Run Parameters dialog. Using a simple posix-style redirect: >writeln.log

Cheers,
David

David Emerson wrote

Yes it is. The problem is that the debugger is not working properly!! The solution is to redirect the program's writeln output, via the Run Parameters dialog. Using a simple posix-style redirect: ?>writeln.log

As the other Martin suggested, simply use MSEide. Its debugging is *much* better than Lazarus IDE, and debugging console apps is not a problem, because MSEide has a special console output window as part of the IDE. If you are developing for fpGUI anyway, you shouldn't have any troubles switching IDE's. I switch constantly between Lazarus IDE and MSEide, even for the same project. No offense to any one here, but that is the beautify of free and open source software - no loyalty required, simply switch to what works better. ;-)

The debugger is not part of Lazarus, so it can give headaches depending on the debugger (kind and version) installed on your machine.

DoDi

David Emerson wrote

I did try the run parameter:>logfile ...a basic redirect. And it worked! program output was redirected to the file,

in rev 29002 a very basic solution has been applied.

In the debugger option you can specify a tty (for in and output of your app) Default is /dev/null, and /dev/null is also used if the config doesn't exist (or isn't a tty)

I am aware that isn't very comfortable. It is only a first step....

Great !

I see that here (Suse) tty1, tty2, tty3, tty4, tty5, and tty6 are attached to the consoles I can switch to by alt-shift-F1, alt-shift-F2, alt-shift-F3, alt-shift-F4, alt-shift-F5, and alt-shift-F6,

I suppose I can as well open a Terminal in the GUI and it will be connected with a /dev/tty?? interface. How to find out which is used by a Terminal Window to make use of it in the debugger ?

Thanks,
-Michael

Afaik type "tty" as command, and it will print what it is.

If you open a terminal for this, as very first thing on startup, you propably always get the same. There may also be a way, to force a new terminal to use a specific tty, but i do not know....

Martin wrote

Afaik type "tty" as command, and it will print what it is.

Great ! Works:

mschnell at ms-Linux-native:~> tty
/dev/pts/2
mschnell at ms-Linux-native:~> echo 1234567890 > /dev/pts/2 1234567890

If you open a terminal for this, as very first thing on startup, you propably always get the same.

Not with the X11 based Terminal program provided by my Suse.

There may also be a way, to force a new terminal to use a specific tty, but i do not know....

Good but not really necessary.

Thanks a lot,
-Michael

Martin wrote

On 08/01/2011 00:55, David Emerson wrote: > > I did try the run parameter:>logfile > ...a basic redirect. And it worked! program output was redirected to the

file,

Still, this is really cool! A great first step.

~David.

David Emerson wrote

Still, this is really cool! A great first step.

+1
-Michael