[solved] Project configuration - how to jump to breakpoints?

[Nicole]

There is a project, where the debugger does not jump to breakpoints any more.
I am not sure, which configuration shall be responsible for this, not am I aware I would have changed anything.
What can I do?

Other projects "jump fine".

[JuhaManninen]

There is a project, where the debugger does not jump to breakpoints any more.
I am not sure, which configuration shall be responsible for this, not am I aware I would have changed anything.
What can I do?

Compile with debug info. See project settings.
The build modes "Debug" and "Release" are useful. During development use the debug mode and finally build an optimized binary for release without debug info.

[Martin_fr]

When you say "jump" (or not doing so), do you mean
1- the debugger does not even pause the app
2- the app does pause, but the source window does now "jump" to the location

Tools > Option > Debugger > Debugger Backend
Which debugger are you using: gdb or fpdebug  (On Mac: lldb+fpdebug)

Also, what OS?


For 1:
check the debug info setting.
check if you use an external debug info file, if yes try to delete any *.dbg file by hand

For 1 and 2:
Are there any symlinks to your project folder, or the files themself. Are files in the IDE open via the symlink? Is fpc configured to use the symlink?

For 2:
Have the breakpoints any properties set (or unset)? "break" should really be set, autocontinue maybe not.
go to the breakpoint, unset it, and set it again (while NOT debugging), then debug again.

---
Any recent upgrades to fpc or Lazarus?
Have you nav

[Nicole]

Thank you for your answers.

Where can I find the modes "Debug" and "Release"?

Tools > Option > Debugger > Debugger Backend
I found:
FpDebug
and overwrote it by gdb

I restarted Lazarus and tried some settings, nothing helped.

operating system:
Win 7 64 bit via VM

dbg file is deleted

What is a "symlink"?

No properties set to the breakpoints, I set them in many lines in a row, even made a "ShowMessage('hi');, - which is shown. But no breakpoints happens.

Lazarus 2.2.4, which I use for a while now. The start of the project should have been with 2.2.2.

[Martin_fr]

"symlink" / "symbolic link" on Linux "ln - s" a sort of 2nd name for the same file/folder.  It is possible to have them on Windows too, but very unlikely.

Are there any "blue dots" on the lines on which the breakpoints do not work?
That is normally if you run in the debugger, lines in your code will have a blue dot in the gutter.

If they do not have a blue dot, the debugger does not know them, and can not break there.

Are the files your own code, part of your project? Or are they part of a package, or part of the rtl (fpc)?

[Nicole]

Most files are my code. And nearly the same has worked before. The code was running for several weeks (I have a shared folder on my host, which allows to run the same code / exe on my Win 10 host and to debug the file from the Win 7 VM).

Then I discovered an annoying bug, - and cannot set the breakpoint before.

All dots are red, they look as they have looked before as the "jump" had worked. And: not a single breakpoint works. I set them in other lines as well.
So: The problem shall be somewhere in the configuration.

Unfortunately the thing is highly nested in VM and host, even the paths and names are part of the Win 10 configuration. Otherwise I would just import the files into a new project. This I want to avoid, if there is any other way.

[Martin_fr]

All dots are red, they look as they have looked before as the "jump" had worked. And: not a single breakpoint works. I set them in other lines as well.
So: The problem shall be somewhere in the configuration.

So when your app is not yet running the breakpoints are red, with a question mark.
But once your application is running, the question mark changes to a green check-mark in a still red breakpoint (grünes Häckchen in rotem breakpoint)

Also, I did ask for the small blue dots. If you remove the breakpoint, there should be a small blue dot in its place.

In the breakpoint properties (see image) there is
- no condition
- break is checed

You have tried with both? (image 2)
- fpdebug
- gdb

In your "project options" there is also a tab "Debugger".
It has the selection "Debugger Backend" = "Use IDE default debugger"

Also in the project options, tab "Debugging" you have
- "generate info for debugger" CHECKED
- "type of debug info" Dwarf
- "use external debug info" : NOT checked
- "code for valgrind" : NOT checked

You have gone through the project folder (and all relevant folders), and made sure
- there is no *.dbg file.
- There are no old exe files. Only one exe,

Then go one step further, do a clean build. Go to your exe folder, and make sure you remove all *.ppu and *.o files.
Then compile and debug again.

Start the debugger from the menu.
In case you have set your "F9" key to "run without debug"


If none of this helps:
- set the debugger to "gdb"
- Open from menu: view > ide internals > debug output  (this must be done BEFORE starting the debugger)
- debug

Once the debugger is running and your app is started:
- copy the entire content of the "debug output" window (there will be content, even if breakpoints do not work / if not, you did not use gdb)
- save the content, and upload (or send by mail, if any of the names in the output are private)

[dseligo]

Most files are my code. And nearly the same has worked before. The code was running for several weeks (I have a shared folder on my host, which allows to run the same code / exe on my Win 10 host and to debug the file from the Win 7 VM).

Try everything Martin_fr said, but also try to copy your code to another directory on machine where you have Lazarus and try to run and debug from there.
Maybe there is some problem with shared folder.

Can you try to debug from Win 10 host?

[af0815]

I never run from shared folders or online synced folders. In the past such projects are not deterministic for me. For sharing the same code i use svn or git. So i have the same code on all used plattforms in sync. And thhe lib folders are not in therepository, so you can not get stucked by wired ppu problems between platforms special win10/32, win10/64 win 7, Debian64, Raspian32,.... .

[Nicole]

Martin (and other), thank you for your posting (see screenshots).
I tried the list until above the options, because something very strange happened:

As I tried to MOVE the window of my app, there was suddenly an exception, which read:

Projekt project_Notizen hat Exception-Klasse »External: SIGSEGV« ausgelöst.

I never saw this before

(Note about shared folders: The idea is not to share the source, but the exe-file. I can start the exe from the VM as well as from the host. And yes, if it is started on the host and I try to run it from within the VM, I see an error message. This is not the problem and not the topic. Nothing about the host shall be a topic with this breakpoint-problem. This happens on a VM with Win 7. And only started from there.)

[Nicole]

at runtime

[Martin_fr]

"at runtime"

- no blue dots
- no checkmarks

The 2 green bars in a breakpoint mean "on hold". That is the debugger was not able to set them, as (from the debuggers point of view) the lines to not yet exist. (only lines with a blue dot exist).

"On hold", because if your app uses "LoadLibrary" code for those lines may still get loaded.


Obviously, you are sure those lines do exist. => But for the debugger they only exist, if:
1) fpc produced line info for them.
2) the line info can be found.

Assuming that by now everything has been checked, and the settings to produce line info are all set correctly (and that you also cleaned out all and any old file, that may have been outdated, yet not been replaced....

Then the issue is "2 can be found"

The debugger finds them by the file-name. And that is the file name that the IDE gives to the debugger. (the file name the IDE shows in the status bar of the editor).

That is only found, if fpc has put the same filename into the file.... Well why shouldn't it??
- I have no idea how fpc deals with those network share names.
- Maybe fpc compiled it, using the local path names of the host system
- depending on the include path settings given a file "C:\foo\bar\test.pas" fpc may encode this as folder "C:\foo\" filename "bar\test.pas" => and then it will never be found.
  (I am not sure when this happens, or if it still happens / I have seen that long ago...)


If you only want to share the exe, then add a path to the "output filename (-o)".
And keep all other files local.
Don't modify any other settings that deal with pathes.


You can use "objdump" to see the filenames that ended up in the exe. But that produces a lot of data to check.
  objdump --dwarf=rawline  yourapp.exe
(or maybe it was rawlines or raw_line / check the help)
Then search for parts of your folder names, and file names.

[Martin_fr]

Btw, if it is such file-name issues, then FpDebug may have a better chance to get around it than gdb.

If - as you said - you are on 2.2.4  then you are using gdb (were using gdb when you made the screen grabs)

[Nicole]

thank you so very much for your patience!

in your "project options" there is also a tab "Debugger".
It has the selection "Debugger Backend" = "Use IDE default debugger"

Also in the project options, tab "Debugging" you have
- "generate info for debugger" CHECKED
- "type of debug info" Dwarf
►►► - "use external debug info" : NOT checked
- "code for valgrind" : NOT checked

► this was checked, no idea why and how and etc.

and  now * jump * jump * jump *