Breakpoint dosn't work

[LemonParty]

Hi.
I am trying to debug my program and placed several breakpoints. Genereting of debug information is on. But when I start program using F9 non of breakpoints are triggered. Lazarus v 3.4. In Lazarus v 3.2 I haven't seen such problem. Is there a known bug?

[dsiders]

Hi.
I am trying to debug my program and placed several breakpoints. Genereting of debug information is on. But when I start program using F9 non of breakpoints are triggered. Lazarus v 3.4. In Lazarus v 3.2 I haven't seen such problem. Is there a known bug?

Depends on where the  breaKpoints are set. Are they in FCL or RTL code? Library code which may not have debug info included?
Too many question and very little detail.

[d2010]

In my Win10 , debug with Lazarus, not work, because Microsoft Antivirus, checking, checking checking the vius , very long time.
Buy In Win7, or Win8, Lazarus can work very nice.

[Martin_fr]

As Dsiders said, what unit?

And, if the app runs, are there (in that unit) little blue dots in front of some of the line numbers?

If it is a unit with code you wrote yourself, did you compile with
- optimization off, or level 1
- Debug info enabled
- Debug info type: Dwarf (any of the Dwarf options)
- NO strip of the exe
- ideally, though not mandatory: NO external debug info

What OS?

Go to menu TOOLS (On Mac: Preferences) => Options
then page: Debugger Backend.
On the top of that page (in the toolbar) should be either
- ...(FPDebug)
- ...(GDBMI)  or ... (GDB)
- ... LLDB with FpDebug

which one is it?

[Martin_fr]

There is no known bug or difference between 3.2 and 3.4

It most likely is a setting on your site.
It could be your antivirus.

[LemonParty]

No, it is my code without external libraries. I started a simple project with 1 form and 1 button. Breakpoint in OnClick event not working. I don't see blue dots when run program.

[Martin_fr]

What about the setting, I asked?

No blue dots, usually means there is no debug info.
In really rare cases, it means broken debug info. (e.g. if you specify -gw4 for Dwarf-4  and have the wrong fixes version of fpc / which according to your post, you do not)

[Martin_fr]

Also check you haven't in "project options" set disabled the default for run as "Run uses the debugger"?

The run menu should have "run" and "run without debugger", and you should have chosen "run" (or F9 or the green arrow in the toolbar).

But, if the "run" menu has "run with debugger" instead, then F9 and the green arrow will not use the debugger.

[Joanna from IRC]

Hi.
I am trying to debug my program and placed several breakpoints. Genereting of debug information is on. But when I start program using F9 non of breakpoints are triggered. Lazarus v 3.4. In Lazarus v 3.2 I haven't seen such problem. Is there a known bug?

I sometimes have problems unwanted breakpoints too. You will need to delete all breakpoints and start over.

Menu view..debugwindows..breakpoints.. wisk broom icon

[LemonParty]

I found the solution. Debugger was not added at Project options - Debugger.

[Martin_fr]

I found the solution. Debugger was not added at Project options - Debugger.

But that should fall back to the IDE defaults => Tools > Options > Debugger > Debugger Backend.

So make sure that this is setup. (It should be on every new install, so I wonder if/how that gone missing on your setup)

[Joanna from IRC]

I have gnu debugger installed and I still sometimes have breakpoints that don’t go away unless I clear all of them? What could be causing that? I thought op might have same issue as I do...

[Martin_fr]

I have gnu debugger installed and I still sometimes have breakpoints that don’t go away unless I clear all of them? What could be causing that? I thought op might have same issue as I do...

Well, depends if they use gdb, lldb or fpdebug...
But given, they did not see blue dots, the issue would likely have been something else.

There are issues known, if files in the IDE are reachable via sym-links. (does NOT exactly match your description... / breakpoints do work, but don't show a red dot in the unit)
If the IDE uses either the direct or the sym-link access, but the compiler uses the other.  In the debugger breakpoints use only the file-name (if the path does not match) => usually each unit name can exist only once. In the IDE full path is usually used.
The debugger must take that approach, because the compiler sometimes stores relative paths, so that the full path wont match (and if the debugger is gdb, then smarter search can not be done).

Other issue may or may not be in gdb itself. I am not aware off them. If so then "reset debugger" should also help.

[Joanna from IRC]

One thing I forgot to add, when I am stopped at a break point I didn’t set it shows a green arrow pointing to the right instead of an orange dot. I also noticed the blue dots. Other parts of the code don’t have blue dots in gutter even if I set a break point. I don’t really understand why 

[Martin_fr]

Make sure not to use external debug info => that adds extra pitfalls.  (e.g. old *.dbg file still on disk)
If there are issues, eliminate that factor.

Get rid of all ppu files, so the compiler must do a clean compile of everything.
Not sure if/when that may make a diff. But lets eliminate.

If some entire units don't have blue dots, then
- check they were compiled with debug info (e.g. if in a package)
- they aren't accessed via sym links (neither IDE, nor compiler)
- otherwise, its an yet unknown issue.

If some function or blocks of code don't have blue dots
- are they called / are they dead code
- are the "type TFoo = object ... end" => only 3.3.1 writes full debug info for those
- generics, in case of older fpc (iirc < 3.2.2)

If blue dot mis match the lines with code => force recompile that unit. (delete ppu)

If breakpoints don't show in source, but in breakpoint window (and if you stop at them, they should, otherwise your gdb is broken), then make sure no symlinks are involved.
That happens if and when the compiler saw a diff filename than the IDE.

With older fpc, that can happen for generics.

If you didn't set a breakpoint, and it does not show in the breakpoint window either => then check the gdb output
Menu: View > IDE Internals > Debug output.
There should be as "stopped... reason..." line.

Some versions of fpc write wrong info (not sure which, need to search for the bug report again).

In that case breakpoints at the very end of one function can trigger at the very start of the next (even across unit boundaries).  Such breakpoints can also crash the debugged app... That can only be fixed in fpc.
FpDebug ignores such wrong info.