Debugger 'Sometimes' Works

[kevin.black]

MBP Mojave
Lazarus 2.0.0RC3
x64 Cocoa

I have a DYLIB and a test app. The debug option in both are basically the defaults. On trying to run the application one of three things is happening:

• The application starts, but never gets past/to the initialise code, ie. the system thinks there is a debug session, but it's just'stuck'
• The application runs and after several minutes (yes it is a really, really long time) the show message dialog in initialize appears and the app runs, but does not debug (ie. don't stop at breakpoints etc)
• As above, but debugging works and it actually (rather fantastically) debugs into the DYLIB after a call

Obviously option 3 is ideal, but 99.99% of the time it's option 1 so I have a gazillion showmessage lines or writelog lines or both to try and debug. These lines in and of themselves are causing grief when you are in a tight loop servicing requests that are taken up with showing messages.

So, in simple terms, what do you think I'm doing wrong?

What are the basic (and likely to succeed) settings for the debugger in an OSX/Cocoa  environment?

EDIT: I'm guessing the 'Generate debugging info for GDB' should be unticked.

Thanks....

[Martin_fr]

Lots of questions....

You mention "gdb". Do you use the gdb based, or the lldb based debugger?
(I know the IDE dialog also still refers to gdb, even so some applies to lldb too)

"Generate debug info for gdb" must be ticked for lldb too.

Debug info type: "Dwarf (with sets)" should be fine.
With "lldb (with fbdebug) you may get good results with "dwarf 3" too.

You may want to try "external debug info" versus not using it.
If you have used it, then remove the folder projectname.dSYM (or the debugger keeps looking at the old folder / even though it would/should ignore it *after* reading all of it)


I base the rest of my reply on the assumption that you use lldb+fpdebug.

Please read
https://forum.lazarus.freepascal.org/index.php/topic,44967.0.html
You may want to upgrade to 2.0.  Or better fixes branch. There are some issues fixed.

You may also follow
https://forum.lazarus.freepascal.org/index.php?topic=44950.new#new
This is also an issue during starting the project. Though you do not get the crash. And the nil pointer deref should always cause it.

Speed:
Go through the packages used. Any package you do not debug, disable debug info. Less for the debugger to read.  (You can do that via "Additions and overrides" / see wiki)
It may not make a big diff though.

Also ensure there is no outdate *.dSYM folder.

Optimization 1 vs 0

0 is better. (for debugging)
1 can affect watches. In rare cases watch values may not be updated on each step, if 1 is used for optimization.

0 or 1 should not affect the startup

There is a package "LazDebuggerLldb"  without any "fp" in it. You can install it for testing pure lldb debugging.
Be warned: all watches will be displayed c-style.
And they must be inputed c-style too "form1->Ffield".

But in case the issue if with the "fpdebug" part, this would be a workaround.

See the first link above.
It has details how to provide a logfile.

You specified 64bit.

That applies to both:
- your IDE (Lazarus build 64bit, rather than cross-debugging)
- your own app
?

[kevin.black]

@Martin_fr

Wow, great response thanks.....

You mention "gdb". Do you use the gdb based, or the lldb based debugger?
(I know the IDE dialog also still refers to gdb, even so some applies to lldb too)
"Generate debug info for gdb" must be ticked for lldb too.

lldb, wasn't sure (it's confusing), I can easily reenable.

Debug info type: "Dwarf (with sets)" should be fine.
With "lldb (with fbdebug) you may get good results with "dwarf 3" too.

I'll try dwarf 3 - something different that might work.

You may want to try "external debug info" versus not using it.
If you have used it, then remove the folder projectname.dSYM (or the debugger keeps looking at the old folder / even though it would/should ignore it *after* reading all of it)

OK

I base the rest of my reply on the assumption that you use lldb+fpdebug.

Correct....

Please read
https://forum.lazarus.freepascal.org/index.php/topic,44967.0.html
You may want to upgrade to 2.0.  Or better fixes branch. There are some issues fixed.

Will do, I was trying to keep a base level Lazarus (I have trunk and fixes installed, but was avoiding to use the latest release candidate). That obviously may not be the best option.

You may also follow
https://forum.lazarus.freepascal.org/index.php?topic=44950.new#new

I saw that, but tuned out when there was a deal of code invoking some debug options. I will revisit.

This is also an issue during starting the project. Though you do not get the crash. And the nil pointer deref should always cause it.

I'll look at that. I've been using initialization / finalization blocks, but these seem to have the subtle glitches you mention. I might dispose of them and just use the onCreate and onClose procedures.

Speed:
Go through the packages used. Any package you do not debug, disable debug info. Less for the debugger to read.  (You can do that via "Additions and overrides" / see wiki)
It may not make a big diff though.

At least it's somewhere to start.

Also ensure there is no outdate *.dSYM folder.

OK

Optimization 1 vs 0

0 is better. (for debugging)
1 can affect watches. In rare cases watch values may not be updated on each step, if 1 is used for optimization.

I had no idea, logically '1' seemed like it was the way to go based on the wording, ie. 'debugger friendly'.

There is a package "LazDebuggerLldb"  without any "fp" in it. You can install it for testing pure lldb debugging.
Be warned: all watches will be displayed c-style.
And they must be inputed c-style too "form1->Ffield".

But in case the issue if with the "fpdebug" part, this would be a workaround.

Whenever you say 'be warned' I think I'll leave it for the time being

See the first link above.
It has details how to provide a logfile.

OK

You specified 64bit.

That applies to both:
- your IDE (Lazarus build 64bit, rather than cross-debugging)
- your own app

Both....