Debugger 'Sometimes' Works lazarus / 12-Debugger ---------------------------------------------------------------------- kevin.black · 2019-04-08 00:02 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 · 2019-04-08 00:53 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 · 2019-04-08 01:24 @Martin_fr Wow, great response thanks..... Quote from: Martin_fr on April 08, 2019, 02:53:10 amYou 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amDebug 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amYou 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 Quote from: Martin_fr on April 08, 2019, 02:53:10 amI base the rest of my reply on the assumption that you use lldb+fpdebug. Correct.... Quote from: Martin_fr on April 08, 2019, 02:53:10 amPlease 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amYou 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amThis 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amSpeed: 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. Quote from: Martin_fr on April 08, 2019, 02:53:10 amAlso ensure there is no outdate *.dSYM folder. OK Quote from: Martin_fr on April 08, 2019, 02:53:10 amOptimization 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'. Quote from: Martin_fr on April 08, 2019, 02:53:10 amThere 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 Quote from: Martin_fr on April 08, 2019, 02:53:10 amSee the first link above. It has details how to provide a logfile. OK Quote from: Martin_fr on April 08, 2019, 02:53:10 amYou specified 64bit. That applies to both: - your IDE (Lazarus build 64bit, rather than cross-debugging) - your own app Both....