Hi,

As old users know there was a problem about breakpoints that after removing or changing code still debugger will stop at an imaginary line. Years ago it seems solved as I read mail list but I have this problem from day one of using Lazarus and my only solution is removing them from breakpoint list.

I want to ask is the problem want to go away or Im doing something wrong?

Regards, Ara

There are at least 2 different known causes. (both have been addressed in the past, but there still can be conditions under which they exist)

1) Breakpoint is in correct file (including full directory), but different line
2) Breakpoint is in a file of equal name, but different directory. (usually symlink to file/folder)

1) As long as the blue dots (during debugging) are showing for a file the line should be traced. However replacing multiple lines (via paste/override selection) will move it to either start or end of the newly pasted lines.

2) Do not open files with symlinks. if you did, search through your xml files (lpi, lps, and primary-config-path) and clean them.

If it is symlinks, I do not know how much can be done. Otherwise exact steps to reproduce are needed

Its almost first condition but I removed breakpoint but it debugger think it still there.
I will try to to reproduce it,its hard becuse it finds out suddenly but as I understand it mostly happen in other packages not the project.

Regards,
Ara

1)
Most Important:
- OS? (Version?)
- CPU?
- Lazarus 1.4 ?
- fpc 2.6.4?
- gdb version (on windows 32 bit, it is 7.2 if you use the normal installer)

2)
So it is also gone from the list in the breakpoint window? (Menu "View"

" Debug Windows")

3)
Do you remove the breakpoint, while the program is
- running
- paused
- debugger stopped
- dgb starting up / pressed F9, but not yet seeing your app on screen
- dbg stopping

4)
This is all in a single debug run? Or do you debug, end debug, start a new debug, and in the new debug a breakpoint still exists, that you removed?

5)
Does the code contains any threads?
On Windows: Does it happen shortly after (up to a minute) after using a file open/save (or other file/print/system) dialog? Many of them create threads.

If you can keep the thread window open, so you see if there are any threads. (On Windows, hitting pause, creates ONE extra thread)

6)
Try running Lazarus creating a logfile:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session When you exit/ restart the IDE, delete the log, or it keeps growing. When the issue happens again, send the log (if to big for the mail list, you can sent directly to me, or attach to a bug created)

When it happens, notice filename and line where the debugger stopped., then stop the debugger, without doing any further debugging, and exit the ide, so the log will be correctly finished.

-------------------------------------------------
Alternatively, if the above is too much / taking to long, then you can try to:
- in tools option "reset debugger after each run?
- on Windows 32: use the gdb 7.7.1 (alternative gdb) from the Lazarus SourceForge site

1) Windows 8.1 64 bit but it also happened in 7 64bit. CPU's are Intel core 2 (recent) and A new AMD model that I couldnt remember. fpc yes 2.6.4 and Lazarus 1.4 32bit and gdb is default.all are default and was default.this problem is here for last 3 released version.

2) No they are in the breakpoints list but when you dbl click or want to go to the line,Lazarus cant find the line.

3) I have doubt about it but as I remember yes I changed code and breakpoint in the middle of debugging but not always I think.

4) Single debug ,also many times it will be there after closing and opening the project again and again until suddenly it be removed or sometimes I made breakpoint in the line and propitious and next lines and remove them.

5) No.

6) OK I will.

Is gdb 7.2 used for last 3 Lazarus release?because I have this problem from the first time I met Lazarus and I think it 3 or 4 version ago.

Regards,
Ara

aradeonas wrote

2) No they are in the breakpoints list but when you dbl click or want to go to the line,Lazarus cant find the line.

Have you compared the Path in the filename? (You can see the path, by opening the properties of a breakpoint)

The line does exist in the file, I assume?

Have you edited the file after F9 (Answer 3 suggests you may have?)? If so are the blue dots correctly aligned with the code?

Is there any error, when the IDE does not jump to the line for a "hidden" breakpoint. (messages window)
If there is not, then use the log (below) and see, if any error is in the log (or mail it)

After your answer above (2), the gdb version is very unlikely to affect this. This was in case the IDE tried to delete it, but gdb refused. But the IDE still has it, so gdb is yes 7.2 has been used a long time.

As for the log. Reduce it to:

--debug-log=LOG_FILE --debug-enable=DBG_STATE,DBGMI_QUEUE_DEBUG

----------------------------------
unrelated. There is a common win7/8 issue (but absolutely not related): http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#On_Windows_Open.2FSave.2FFile_or_System_Dialog_cause_gdb_to_crash

Yes,File is correct,I removed a breakpoint and change code but debugger think its still there. Yes line exists but Line/Length column in BreakPoint viewer is 0 most of the times. Yes I edit file.But I dont know what you mean from "blue dots". No there isnt any error.

his was in case the IDE tried to delete it, but gdb refused. But

the IDE still has it, so gdb is is?BreakPoint viewer show there should be a breakpoint but code editor doesnt and debugger think there is so?BreakPoint viewer and debugger think same.

Regards, Ara

Do you at any time replace (e.g. copy and paste -- undo/redo -- delete-all/undo ) the content of the entire file? Or at least from line 1 to the line with the breakpoint?

undo only undoes the text, but the breakpoint pos might in some cases be off, after the undo.

replacing lines, moves breakpoints in the replaced range, to (iirc) the top of that range.

aradeonas wrote

Yes,File is correct,I removed a breakpoint and change code but debugger think its still there. Yes line exists but Line/Length column in BreakPoint viewer is 0 most of the times.

Ok it all sounds as if some part of the IDE thinks there is a different file.
Is it a file in your project (main folder or via some path), or is it in some package?

Do the logfile anyway, it should tell what filename and path the IDE sends to GDB. And also the line number. (see below)

"line" is 0... Interesting.

Yes I edit file.But I dont know what you mean from "blue dots".

When you run your app, there should be blue dots in the gutter for any executable line.

Intersting is BreakPoint viewer show there should be a breakpoint but code editor doesnt and debugger think there is so BreakPoint viewer and debugger think same.

Where exactly does the debugger stop in that unit?

First line of first procedure? Or the actual line in which the breakpoint used to be, before it became corrupted?

--------------------------
Some background.

A breakpoint at line 0 can not be shown in the editor. (since first line is 1). However if setting a breakpoint in gdb to a line with no code (line 0 has no code) gdb searches the next line with code, and sets it there. (set a breakpoint on an empty line, will stop on next line) This can be useful (if its just 1 or 2 lines off), and harmful if its 100 or more lines away (e.g. in the interface section)

So if you stop at the first line of code in the unit, then you got a breakpoint at line 0, and that can not be displayed in the editor. The question is, how it moved to line 0.

Something else:
1) when you edit a file while NOT debugging, breakpoints move as you insert/delete lines (obviously)
2) edit a file while debugging, they still move, but only in the IDE. Because the exe in the debugger still needs the old positions. So if procedure Foo is at line 500 to 550, with a breakpoint (in foo) at 510; and you delete 5 lines somewhere before 500, then in the SourceEditor Foo is from 495 to 545 (but the loaded exe still is from 500 to 550) The IDE then maps the breakpoint (that is now displayed at
505) to still stop at 510 (in loaded exe). This map is reset when the debugger stops.

Maybe there is an issue with that map...

Martin Frb wrote

"line" is 0... Interesting.

you said

Its almost first condition but I removed breakpoint but it debugger think it still there.

Does that mean:

- The breakpoint is there (red mark in the gutter)
- You click it, and it disappears from the editor
- Now you discover it is still there?

Do you at any time replace (e.g. copy and paste -- undo/redo --

delete-all/undo ) the content of the entire file? Or at least from line 1 to the line with the breakpoint?

Yes but not all time this problem happen.

Is it a file in your project (main folder or via some path), or is it in

some package? Mostly package but it without any duplicate so make IDE wrong.

When you run your app, there should be blue dots in the gutter for any

executable line. Excuse me but still I can understand what you mean.

Where exactly does the debugger stop in that unit?

First line of first procedure? Or the actual line in which the breakpoint used to be, before it became corrupted? Mostly on the end of procedure.

A breakpoint at line 0 can not be shown in the editor. (since first line

is 1). However if setting a breakpoint in gdb to a line with no code (line 0 has no code) gdb searches the next line with code, and sets it there. (set a breakpoint on an empty line, will stop on next line) This can be useful (if its just 1 or 2 lines off), and harmful if its 100 or more lines away (e.g. in the interface section) BreakPoint viewer shows line 0 but its not about first line,it just cant find the line,for correct breakpoints when you dbl click editor go to it but for these one nothing happen.

2) edit a file while debugging, they still move, but only in the IDE.

Because the exe in the debugger still needs the old positions. So if procedure Foo is at line 500 to 550, with a breakpoint (in foo) at 510; and you delete 5 lines somewhere before 500, then in the SourceEditor Foo is from 495 to 545 (but the loaded exe still is from 500 to 550) The IDE then maps the breakpoint (that is now displayed at
505) to still stop at 510 (in loaded exe). This map is reset when the debugger stops.

Yes it just happens for me and ?I saw it for example all of breakpoints in a procedure go 2 line down.

Regards, Ara

I forgot to mention I use JCF formatter much,maybe it is the reason,I will focus on it and when I found a way to reproduce it tell you.

Ara

Martin just now I have this problem :

BreakPoint viewer shows one breakpoint at line 291 but debugger wait on line 303 on begin of next procedure.when I remove procedure debugger wont wait but if I put it back on 291 it will wait on 303. I restarted IDE but problem still there and log only shows breakpoint on line 291.

Regards, Ara

Try to keep watching those actions. In case any of them sets the line no to 0

Mostly package but it without any duplicate so make IDE wrong.

Right lets ignore filename and path. It seems the issue i on the line number.

Excuse me but still I can understand what you mean.

As in the image. Blue dots in the gutter. (they are red on lines with breakpoint)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150624/02329292/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: hehgbdjh.png
Type: image/png
Size: 2523 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150624/02329292/attachment.png>

aradeonas wrote

I forgot to mention I use JCF formatter much,maybe it is the reason,I will focus on it and when I found a way to reproduce it tell you.

JCF may indeed not preserve breakpoints.

Ok, so the internal bap of the debugger is somehow incorrect. I assume all the above actions were within one debug session?

The IDE seems to assume that you deleted lines.

Now if you delete lines while debugging, the exe is not recompiled. Delete 12 lines before 290, and the code that was at line 303 will be at line 291. (That is in the editor)

But in the exe in the debugger it would still be at line 303. SO if indeed those lines where deleted, then setting a breakpoint at 291, needs to set a breakpoint at what was 303 at compile time.

BEst to open an issue on the bugtracker.
I'll need to see how best to find additional info what causes this (that is why the IDE thinks you deleted lines, when you did not)

Take a look at attachment,as you see blue dots are at all lines except the procedure that breakpoint is in it.Also as you can see debugger wait on 303.

BEst to open an issue on the bugtracker

Yes but I have problem to reproduce it.

Regards, Ara

Ah, that looks like a different issue. There are no blue dots for that usually means this procedure was not compiled
into the the procedure is not in the exe, then gdb thinks there is no executable code on that line 291, and it sets the breakpoint on the first line with code that it can find after that. (Yep in that case it be better to not set a breakpoint at all, and mark the breakpoint as invalid, but that is not (yet) implemented).

By any chance, do you have smart linking enabled?
http://wiki.lazarus.freepascal.org/Debugger_Setup#Project_Options -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150624/9135372c/attachment.html>

But code is in exe and line works,I put a log in that line and it works. No I havent and options are as wiki : Link smart= False; (wiki screenshot seems outdated) Ara

aradeonas wrote

But code is in exe and line works,I put a log in that line and it works. No I havent and options are as wiki : Link smart= False; (wiki screenshot seems outdated)

Can it be that the lines are inlined?

Please check, if those dots are missing right away, when you start debugging and have not (since compiling) edited the file.

or open the exe in gdb, and check if there is debug info for this line gdb -mi yourexe.exe

info line yourunit.pas:291

Should return something like:
Line 291 of \"include/control.inc\" starts at address 0x543105 <SETTEXT+325> and ends at 0x5433d1 <SETTEXT+1041>

info line yourunit.pas:292

If both line have code then the address should go up, if it does not, the fpc did not put debug info for that line, and the debugger can not find it.

Please check, if those dots are missing right away, when you start

debugging and have not (since compiling) edited the file.

Yes they missed when I start right away after opening Lazarus.

or open the exe in gdb, and check if there is debug info for this line

gdb -mi yourexe.exe How? If you mean in command line it says there isnt any -mi.

Also I changed the lines but still if I set breakpoint in that line (now its 280) it still wait at the next procedure's begin.

Regards, Ara

aradeonas wrote

How? If you mean in command line it says there isnt any -mi.

sorry it is
gdb -i mi project.exe

probably a simple
gdb project.exe
will also do

Also I changed the lines but still if I set breakpoint in that line (now its 280) it still wait at the next procedure's begin.

Breakpoint normally only work on lines with blue dots. So if there is no blue dot then that means there is no line of code there.

Well of course in your case there is. But it is unknown to the debugger.
- Either FPC did not generate the info when compiling
- gdb has a bug reading the issue
- the IDE does display incorrect

In the last case the breakpoint would actually work. For the IDE does not check for the blue dot. IT just displays it, but does not use it for any check when setting the breakpoint.

You can try explicitly setting debug info to dwarf2 (with sets) or stabs.

Btw. The above case likely has a different cause than the breakpoint at line 0. So there may be 2 issues.

Btw. The above case likely has a different cause than the breakpoint at

line 0. So there may be 2 issues.

Yes probably.

I checked and and seems nothing.

Ara