Recent

Author Topic: New debugger for Mac based on lldb (Call for testers)  (Read 68683 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #105 on: February 02, 2019, 10:09:09 pm »
That sound like the code that reads the lldb input after running, is not updating the debuggers (LazDebuggerLLdb) copy of the selected thread.

I will have a look.
Unfortunately to late for 2.0.  That is already tagged.

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #106 on: February 02, 2019, 10:28:14 pm »
Thanks...

In the meantime, I added your suggested new code to lldbdebugger but with no effect :-(

Also as info for what I am seeing.
On a line of code where I'm testing:
    FPrice := CleanPrice(GenericSymbol, sentprice);
If I breakpoint here, then set the thread via lldb command, step-in does take me to the "property" function (GetGenericSymbol) to get my Generic Symbol, and I can keep successfully stepping while I am within that function, BUT when I get to the end of that function and "step" out expecting to wind in in CleanPrice before the actual setting of FPrice, I note that the assembler code agains shows some other thread's info methinks, so from lldb's point of view, the correct thread is once again lost.

FWIW, the symptom is that quite regularly the source thread is "lost" to lldb :-)  but I guess I already said that.  I can beat dead horses without request.
« Last Edit: February 02, 2019, 10:32:46 pm by kcandrews »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #107 on: February 03, 2019, 05:05:08 pm »
The code I posted was about "F8" not stepping over, but stepping in. But as I wrote later, it may not work. I have not yet been able to reproduce the issue with lldb, so I can not do much about it.
A logfile (with register and stack window open, so I can see values received for them in the log) might help... maybe/hopefully.

Once step-over paused incorrectly, the stack may be incorrect (hide some callers). If so, please describe the true stack. (top 3 frames)


Threads and stepping. (Still have to look into it)
A log would be welcome too...

To be sure I understand correctly.

1) You want to continue stepping, in the thread that was interrupted by the breakpoint?
But (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)

2) You stop at a breakpoint, change the thread to a different thread, that the one that hit the breakpoint, and then want to continue stepping in the thread that you switched too? But it steps in the thread of the breakpoint?


Also, when you reach the breakpoint, in the thread window, is the correct thread selected?
« Last Edit: February 03, 2019, 05:07:57 pm by Martin_fr »

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #108 on: February 03, 2019, 07:11:09 pm »
Hi Martin,

I don't understand the internals of the Lazarus IDE or debugger code, but am trying to rebuild the Lazarus IDE in debug mode -- with the hope of doing some debugging through lazdebuggerlldb.pas -- though at the moment packages don't seem to be generating the debug output needed to stop at breakpoint source code lines.  (With your knowledge and experience, of course, your efficiency is superior but I thought I'd give this a shot since the OSX environment seems likely to be the issue for the laz lldb code?)

I will try to provide information re: the stack though I'm not sure how exactly to do that.  My last assembly language programming (mostly 8080 and 8086) was back in the 1980's and then moved onto "C/C++" and since I've mainly worked in applications-level programming since then, I rarely even think about stacks :-(

I will do what I can to put together a relevant logfile.

Quote
1) You want to continue stepping, in the thread that was interrupted by the breakpoint?
Yes
Quote
But (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)
Yes, using the capablilty you showed me of being able to send a command directly to lldb, after the breakpoint successfully works, I can select/set the source code thread.  Only then can I use F7 and/or F8 (from the IDE) successfully.  Not sure what you mean by the "main thread" (IDE or my source) but stepping does not occur in my source code thread -- shown by the assembler window not longer showing my source code as it did when the breakpoint occurred.  Without lldb intervention to select my thread, after doing an "IDE" step (F7 or F8), the assembler window shows some other section of code.  (I'll give you attachments to show this.)

Quote
2) You stop at a breakpoint, change the thread to a different thread, that the one that hit the breakpoint, and then want to continue stepping in the thread that you switched too? But it steps in the thread of the breakpoint?
If I don't force lldb to use the thread for my source code, then and F7 and F8 IDE commands cause stepping in what appears to be some other thread.

Quote
Also, when you reach the breakpoint, in the thread window, is the correct thread selected?
Haven't looked at the "thread window" -- but the assembler window at the breakpoint stop is correct (showing my source code lines).  However, unless I then reset the thread to the source code thread directly sending the "select thread" command to lldb, any stepping (F7 or F8) does NOT step through the source code -- and appears to step through some other thread (though if I F9) things proceed again to the next breakpoint.

I'm sure this will become clearer once I get more info/logs about this to you.  I hope to get somewhere with that today :-)

Thanks for your time and patience with me.  I have a lot of coding/architecture/consulting history but as you can tell, I don't know the Lazarus internals landscape at all.
« Last Edit: February 04, 2019, 01:12:10 am by kcandrews »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #109 on: February 03, 2019, 08:53:51 pm »
you missed inserting [ quote ] ... [ /quote ] tags...

I don't understand the internals of the Lazarus IDE or debugger code, but am trying to rebuild the Lazarus IDE in debug mode -- with the hope of doing some debugging through lazdebuggerlldb.pas -- though at the moment packages don't seem to be generating the debug output needed to stop at breakpoint source code lines.
In many cases it is enough, to open menu: Tools > Configure build Lazarus => There you can add options for compiling the IDE. You can use -gw3  (dwarf3). (Should that give unexpected trouble (errors produced by lldb), then use only -gw (dwarf2)).
Also add -O-  to disable optimizations, which could interfere with the debugger.
A good set of options:
Code: [Select]
-gw3 -O- -gh -gt -Criot
Not all package follow this. You can open individual packages from the menu "Package". (If you open LazDebuggerFPLldb first, then you can open LazDebuggerLldb from that package / might be quicker).
Each package has a button "Options". There you can set any options you want.
Both the LazDebugger...Lldb packages should have "$(IDEBuildOptions)" in the "costum options" section of their options. This means they follow the global options.

While usually not needed, if in doubt, in "Configure build Lazarus" choose the "clean all" option.


To debug the IDE, inside another IDE:
- Open the project (inside the lazarus install folder) ide/lazarus.lpi
- Press F9 to run
This will not correctly recompile changes that you made (even if it looks like). If you made changes always recompile from the Tools menu.

If you debug the IDE a lot, open the project (ide/lazarus.lpi), go to menu Run > Run Params, and add as "command line parameters"
  --primary-config-path=/path/to/empty/folder
This allows you to have a separate global config for the debugged IDE.
You can also add any --debug-enable, that you need for logging.


Quote
  (With your knowledge and experience, of course, your efficiency is superior but I thought I'd give this a shot since the OSX environment seems likely to be the issue for the laz lldb code?)
The LLDB debugger was written only for the OSX environment. All other OS are better of with GDB.
Yet I myself am a Windows/Linux user. So most of my development happens on those platforms. I have access to a MAC, which I use for dedicated testing.
But since I do all my normal debugging on Win/Linux, the testing of LLDB on Mac from my side is limited to a few dedicated test runs.

So for stress testing, I have to relay on feedback. And extra help is always welcome.

Quote
I will try to provide information re: the stack though I'm not sure how exactly to do that. 
If you run a logfile --debug-log as specified in the very first post of this thread, then the data will be included in the logfile. All you need to do, is to keep the IDE's stack window open, so the IDE will need the data, and get it from lldb.
The same applies to the register window (from menu View > Debug Windows). Just leave it open.

The stack window has a copy button, to copy its content, but that will not be needed.

What I meant is:
- You may be executing code in FormCreate (or any function / Since you step through it, you know the functions name)
- It makes a call like "Top := 7", you STEP-INTO it.
You are now in TControl.SetTop function. You do know it was called from FormCreate.
But if you look at the stack, it will show
  SetTop
  SomethingInTheLCL
The function FormCreate is missing from the list. Shoud that case happen, then simply say so.

Quote
My last assembly language programming (mostly 8080 and 8086) was back in the 1980's and then moved onto "C/C++" and since I've mainly worked in applications-level programming since then, I rarely even think about stacks :-(
Well all I mean is the high level representation of the Stack. Just look at the Stack window.

Quote
I will do what I can to put together a relevant logfile.

Quote
1) You want to continue stepping, in the thread that was interrupted by the breakpoint?

Yes
Quote
But (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)

Yes, using the capablilty you showed me of being able to send a command directly to lldb, after the breakpoint successfully works, I can select/set the source code thread.  Only then can I use F7 and/or F8 (from the IDE) successfully.  Not sure what you mean by the "main thread" (IDE or my source) but stepping does not occur in my source code thread -- shown by the assembler window not longer showing my source code as it did when the breakpoint occurred.  Without lldb intervention to select my thread, after doing an "IDE" step (F7 or F8), the assembler window shows some other section of code.  (I'll give you attachments to show this.)
So you send for example
Code: [Select]
thread select 5 to the debugger.

And then you press F7 which sends "thread step-in"

Quote

Quote
Also, when you reach the breakpoint, in the thread window, is the correct thread selected?

Haven't looked at the "thread window" -- but the assembler window at the breakpoint stop is correct (showing my source code lines).  However, unless I then reset the thread to the source code thread directly sending the "select thread" command to lldb, any stepping (F7 or F8) does NOT step through the source code -- and appears to step through some other thread (though if I F9) things proceed again to the next breakpoint.
Ok that answers the question I did ask 2 lines above....


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #110 on: February 03, 2019, 09:13:59 pm »
Your previous answer already gave me some idea where to look.

Please try with the following patch
Code: Diff  [Select][+][-]
  1. Index: components/lazdebuggers/lazdebuggerlldb/lldbdebugger.pas
  2. ===================================================================
  3. --- components/lazdebuggers/lazdebuggerlldb/lldbdebugger.pas    (revision 60312)
  4. +++ components/lazdebuggers/lazdebuggerlldb/lldbdebugger.pas    (working copy)
  5. @@ -1175,7 +1175,7 @@
  6.    else begin
  7.      Debugger.FCatchesBreak.Disable;
  8.      Debugger.FPopExceptStack.Disable;
  9. -    Instr := TLldbInstructionProcessStep.Create(FNextStepAction);
  10. +    Instr := TLldbInstructionProcessStep.Create(FNextStepAction, Debugger.FCurrentThreadId);
  11.    end;
  12.    Instr.OnFinish := @RunInstructionSucceeded;
  13.    QueueInstruction(Instr);
  14. Index: components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas
  15. ===================================================================
  16. --- components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas        (revision 60312)
  17. +++ components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas        (working copy)
  18. @@ -133,7 +133,7 @@
  19.    protected
  20.      function ProcessInputFromDbg(const AData: String): Boolean; override;
  21.    public
  22. -    constructor Create(AStepAction: TLldbInstructionProcessStepAction);
  23. +    constructor Create(AStepAction: TLldbInstructionProcessStepAction; AThread: Integer = -1);
  24.    end;
  25.  
  26.    { TLldbInstructionProcessKill }
  27. @@ -713,15 +713,24 @@
  28.  end;
  29.  
  30.  constructor TLldbInstructionProcessStep.Create(
  31. -  AStepAction: TLldbInstructionProcessStepAction);
  32. +  AStepAction: TLldbInstructionProcessStepAction; AThread: Integer);
  33.  begin
  34.    case AStepAction of
  35.         saContinue: inherited Create('process continue');
  36. -    saOver: inherited Create('thread step-over');
  37. -       saInto: inherited Create('thread step-in');
  38. -    saOut: inherited Create('thread step-out');
  39. -    saInsIn: inherited Create ('thread step-inst');
  40. -    saInsOver: inherited Create('thread step-inst-over');
  41. +  (*
  42. +    saOver: inherited Create('thread step-over', AThread);
  43. +       saInto: inherited Create('thread step-in', AThread);
  44. +    saOut: inherited Create('thread step-out', AThread);
  45. +    saInsIn: inherited Create ('thread step-inst', AThread);
  46. +    saInsOver: inherited Create('thread step-inst-over', AThread);
  47. +  // *)
  48. +  //(*
  49. +    saOver: inherited Create(Format('thread step-over %d', [AThread]));
  50. +       saInto: inherited Create(Format('thread step-in %d', [AThread]));
  51. +    saOut: inherited Create(Format('thread step-out %d', [AThread]));
  52. +    saInsIn: inherited Create (Format('thread step-inst %d', [AThread]));
  53. +    saInsOver: inherited Create(Format('thread step-inst-over %d', [AThread]));
  54. +  // *)
  55.    end;
  56.  end;
  57.  
  58.  

In lldbinstructions.pas please also try the commented out code (and comment the active added code).


Background:
The InstructionQueue keeps track of the selected thread (and stackframe). If a command requests to run in a specific thread then it will be selected, unless already done.

Some commands do not request a specific thread. Eg listing all threads gets the same result, never mind the selected thread.
Run F9 runs all thread, so it should not care either.

But step commands need to care. Yet by accident they did not request a specific thread.

So depending on what the debugger did before, and what thread got selected, step command mis-function.




If that does not help, then the next point of interest is at line 1030 (lldebugger.pas)
Code: Pascal  [Select][+][-]
  1.     ParseNewThreadLocation(ALine, AnId, AnIsCurrent, Name, AnAddr,
  2.       Stack, Frame, AFuncName, AnArgs, AFile, AFullFile, SrcLine, AReminder);
  3.     AnArgs.Free;
  4.  
  5.     Debugger.FCurrentThreadId := AnId;
  6.  
Does the debugger get the correct ID for FCurrentThreadId

Add a
debugln(['**** Got FCurrentThreadId ', AnId]);
« Last Edit: February 03, 2019, 09:20:02 pm by Martin_fr »

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #111 on: February 03, 2019, 10:55:30 pm »
The patch worked!  Not passing the threadid to the stepping definitely was the main issue.  Stepping now works for me...I didn't need to go to the next point of interest -- line 1030.

Will report as I test...

I have two attachments as a result of running the IDE from lldb and then debugging out of breakpoint and "achieving" a crash or two.  Each has the tail end of the lldb output followed by a "bt."

1. "Step_Crash" -- may be an lldb problem...see attached file and:
https://github.com/WebFreak001/code-debug/issues/106
https://github.com/rust-lang/rust/issues/29154

(lldb) bt
error: need to add support for DW_TAG_base_type 'FormalDef' encoded with DW_ATE = 0x7, bit_size = 0

**** UPDATE: this may not be a notable issue -- running IDE not from within lldb does not show problem -- did a lot of successful stepping f7 & f8

2. "LLDB_Pause" -- got this to happen by hitting IDE "pause" while debugging beyond a breakpointed section (but running):

    >> Running Instruction:
2019-02-03 15:35:23.989430-0700 Lazarus[18768:4189792] [General] An uncaught exception was raised
2019-02-03 15:35:23.989490-0700 Lazarus[18768:4189792] [General] *** -[NSBigMutableString replaceCharactersInRange:withString:]: nil argument

** UPDATE: for me, I rarely need to interrupt a debug session with "Pause" unless I've created an inadvertent "forever loop" (rare)

Summary: Congrats, Martin.  With the exception suffix and prefix fixes and fixing the step threadID, debugging is functional on my OSX.  I've been delaying going to OSX Mojave 10.14 until laz debugging with lldb works -- and now it does -- at least under OSX 10.13, High Sierra!  Thank you.

« Last Edit: February 05, 2019, 04:43:35 am by kcandrews »

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #112 on: February 05, 2019, 04:42:26 am »
OSX Mojave upgrade from High Sierra 10.13.6 report with hope of using new lldb debugger setup:

[EDIT/UPDATE] 2/8/19 - SUCCESS -- not sure of cause but starting out this time with Lazarus 2.0.0 and "fixed" lldb stuff, after OSX upgrade, all is working as it was in High Sierra, but now in Mojave 10.14.3 :-)

1. Performed standard Mojave OSX upgrade from Apple App Store and updated to 10.14.3 Mojave using new System Preferences/Software Update.

2. Upgraded/installed xcode command line tools using terminal command: "xcode-select --install"  Note Xcode is now 10.1 version.

3. Installed FPC 3.04a  FWIW

4. (2/8/19) needed to manually add line to /etc/fpc.cfg to avoid IDE build problem on link due to not finding library crt10.5.1
Quote
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk.

https://forum.lazarus.freepascal.org/index.php/topic,42657.msg300589.html#msg300589

Thank you Hansaplast!

Lazarus (Cocoa/x86_64) itself worked fine, it and packages could be rebuilt with no issues, big project (also Cocoa/x86_64) compiled and ran outside of the debugger as in High Sierra.  [UPDATE 2/8/19] Lldb debugger setup works as it does in High Sierra -- totally functional for breakpoints, stepping, and previous exception issues (thanks Martin!).

Finally, attempted to debug using lldb (as worked before in High Sierra earlier today).  Was able to get first breakpoint to stop code, but any debug commands F7/F8 stepping, F9 restart-run, failed to get code to proceed (a lot of UI delays occurring with constant spinning wheel icon (processor busy).  Had to kill project executable and Lazarus IDE executable.  Noted that lldb version is lldb-1000.0.38.2 Swift-4.2 -- SAME as in High Sierra 10.13.6.

Tried tinkering with csrutil (OSX System Integrity Protection) which had under High Sierra which had been set to "csrutil enable --without debug" but to no avail.

Oh well, for now, going back to High Sierra :-(  Would love to hear if anybody has succeeded in Lazarus debugging using the new lldb setup under OSX Mojave (along with any upgrade steps I missed).
« Last Edit: February 08, 2019, 06:13:17 pm by kcandrews »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #113 on: February 05, 2019, 06:07:34 am »
The "pause" crash happens in the TMemo code. (between LCL and cocoa). So I guess LCL cocoa still as an issue....

Keep the "Internals" > "Debug Output" window closed, and this should go away.

--
It is also possible that this is an issue in cocoa (similar stuff can happen under linux with certain x-servers).

The text to be inserted was "\\x17EBarDataAccessException?\"
That means that lldb had just paused your app at an exception.

1) In gtk (just example), if an app is paused in an event it received from gtk (mouse/key/paint/...), then x-server can hang.
Who knows if there is something similar.

2) You said you just hit pause. Maybe an issue in lldb, (sending pause and at the same time hitting a breakpoint (raise exception is a breakpoint)).
Though that would not explain an error in cocoa memo code....


-------------------
Btw: future logs, if possible please as text file (pfd looses linefeeds).
You can zip,rar,tar.gz


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #114 on: February 05, 2019, 06:14:38 am »
==EDIT ==
I have an idea in the meantime. So probably no need for the extra log.
<< == END EDIT ==


The step crash... That looks like an issue in the IDE debugger code... But have not yet figured it fully.

Can you check a few things.

When you start the IDE, check the commandline
Code: [Select]
--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,FPDBG_DWARF_VERBOSE_LOAD,FPDBG_DWARF_DATA_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME
It looks like the DBG_CMD_ECHO part may be missing, or maybe have missing/xtra chars.
The relevant data is not in the log. (But other part of the debug output was)
Check that the log has lines like/containig:
   >> >> TDebugProcess.SendCmdLn


Can you compile your IDE with range checking please? (Tools > Configure build Lazarus : add to options: -Cr

I will try further to reproduce. I can see what causes it, but not yet how....

--- EDIT
can you apply this path for more debug info please

Code: Diff  [Select][+][-]
  1. Index: fpdmemorytools.pas
  2. ===================================================================
  3. --- fpdmemorytools.pas  (revision 60335)
  4. +++ fpdmemorytools.pas  (working copy)
  5. @@ -26,7 +26,7 @@
  6.  
  7.  uses
  8.    Classes, SysUtils, math, DbgIntfBaseTypes, FpErrorMessages, LazClasses,
  9. -  Laz_AVL_Tree;
  10. +  Laz_AVL_Tree, LazLoggerBase;
  11.  
  12.  type
  13.  
  14. @@ -638,6 +638,7 @@
  15.  constructor TFpDbgMemCacheSimple.Create(ACacheAddress: TDBGPtr;
  16.    ACacheSize: Cardinal);
  17.  begin
  18. +DebugLn(['!!! CreateCache ',ACacheAddress, ', ',ACacheSize]);
  19.    FCacheAddress := ACacheAddress;
  20.    FCacheSize := ACacheSize;
  21.  end;
  22. @@ -646,6 +647,7 @@
  23.    ): Boolean;
  24.  begin
  25.    Result := (AnAddress >= FCacheAddress) or (AnAddress + ASize <= FCacheAddress + FCacheSize);
  26. +debugln(['!!! HasMem ',FCacheAddress, ', ',FCacheSize, ' Mem ',AnAddress, ', ',ASize]);
  27.  end;
  28.  
  29.  function TFpDbgMemCacheSimple.ReadMemory(AnAddress: TDbgPtr; ASize: Cardinal;
  30. @@ -656,6 +658,7 @@
  31.       FFailed
  32.    then
  33.      exit;
  34. +debugln(['!!! ReadMem ',FCacheAddress, ', ',FCacheSize, ' Mem ',AnAddress, ', ',ASize, ' ', FMem=nil, ' ', Length(FMem)]);
  35.  
  36.    if FMem = nil then begin
  37.      SetLength(FMem, FCacheSize);
  38.  

For this bug, I only need a new log, no new backtrace. So you can start the IDE without surrounding lldb.
« Last Edit: February 05, 2019, 04:44:52 pm by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #115 on: February 05, 2019, 06:16:03 am »
Quote
Mojave
Definetely need to see a log. Check the DBG_CMD_ECHO as it is important in this case.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #116 on: February 05, 2019, 06:38:21 pm »
The "step crash" issue: Please test with rev 60338.

You can download a copy of the  changed file: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/fpdebug/fpdmemorytools.pas?view=markup&root=lazarus&pathrev=60338
And replace the entire file (should work for trunk and 2.0.0)
« Last Edit: February 05, 2019, 06:40:06 pm by Martin_fr »

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #117 on: February 06, 2019, 06:53:33 pm »
Hi Martin,

As info, now using laz 2.0.0 as base but replaced directories fpdebug, lazdebuggers, and lazutils with "working" ones from our recent work.

Quote
The "step crash" issue: Please test with rev 60338.
Replaced the file as suggested, and have no problems with stepping f7 & f8 -- but as noted earlier, even before your 60338 change, I actually couldn't reproduce the "step crash" unless running under the laz IDE under lldb.
Quote
Can you compile your IDE with range checking please? (Tools > Configure build Lazarus : add to options: -Cr
I know you didn't need me to do this in the end but...Interesting that in my setup, Lazarus IDE won't start up successfully with the range check option "Cr" set in the IDE build configuration options.  See the first attachment laz.log generated from this terminal command:
 
lldb /Developer/lazarus/lazarus.app/Contents/MacOS/Lazarus -- --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,FPDBG_DWARF_VERBOSE_LOAD,FPDBG_DWARF_DATA_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME --debug-log=/Developer/lazarus/laz.log

On the IDE "pause" during debugging, I will try to generate a useful log file.  I am not having a crash, but "pause" puts the debugging into a state where I can only "stop" and "reset debugger" to regain control.  Not sure exactly what pause is doing but if I recall correctly, under gdb, "pause" allows for "show execution point" and f9 run to be available.  (Not so with lldb in my setup.)

On Mojave problems, having only one machine I am working with, I have reverted back to High Sierra, and will probably wait until someone else is able to do similar testing under that OS.  (It is fairly painful to go to a new OSX version and then have to go back to previous one -- requiring replacing the entire disk image.)
« Last Edit: February 06, 2019, 07:06:15 pm by kcandrews »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #118 on: February 06, 2019, 07:24:54 pm »
Quote
The "step crash" issue: Please test with rev 60338.
but as noted earlier, even before your 60338 change, I actually couldn't reproduce the "step crash" unless running under the laz IDE under lldb.
This probably occured while stepping into, and therefore pausing on a "begin" line of a procedure/function.
The function needs at least 2 params/locals. One of them a local string var. And then some bad luck. And it is 64bit only

Code: Pascal  [Select][+][-]
  1. var a: integer; b: ansistring;
  2. a:= 1;
  3. pointer(b):= pointer(high(qword));
  4. a:=a;// break on this line
watch a and b (a as first entry in watches). That should likely cause the crash.


Quote
Quote
Can you compile your IDE with range checking please? (Tools > Configure build Lazarus : add to options: -Cr
I know you didn't need me to do this in the end but...Interesting that in my setup, Lazarus IDE won't start up successfully with the range check option "Cr" set in the IDE build configuration options.
So the cocoa code as a range check issue....
Unfortunately fpc for Mac does not resolve the stacktraces. So you need to run in the debugger (breakpoint on fpc_raise_exception).

But this is unrelated. Feel free to bug report it though.

kcandrews

  • Jr. Member
  • **
  • Posts: 50
Re: New debugger for Mac based on lldb (Call for testers)
« Reply #119 on: February 06, 2019, 09:31:40 pm »
So probably of little interest but FWIW re:
Quote
This probably occured while stepping into, and therefore pausing on a "begin" line of a procedure/function.
The function needs at least 2 params/locals. One of them a local string var. And then some bad luck. And it is 64bit only

Code: Pascal  [Select]
var a: integer; b: ansistring;
a:= 1;
pointer(b):= pointer(high(qword));
a:=a;// break on this line
watch a and b (a as first entry in watches). That should likely cause the crash.
In my main form, just as a test I created a new procedure TestMe which I then called at the start of FormCreate:
Code: [Select]
procedure TfrmSystemRulesMain.TestMe;
var
   a: integer; b: ansistring;
begin
a:= 1;
pointer(b):= pointer(high(qword));
a:=a;// break on this line
end;

procedure TfrmSystemRulesMain.FormCreate(Sender: TObject);
var
   i: integer;
   o: TOrderType;
   e: TEvaluator;
   Userdir: string;
   TechRules: TTechRules;
begin
   TestMe;
   ...
I successfully stepped (F7) into and within the TestMe procedure, but on f7 stepping out of the TestMe procedure an exception is raised:
 "raised exception class: 'Debugger stopped with reason: EXC_BAD_ACCESS (code=1,address=0xffffffffef)'

Commenting out the line "pointer(b):= pointer(high(qword));" eliminates the exception.

Also possibly interesting is that doing a try/except around the line  "pointer(b):= pointer(high(qword));" fails to trap the exception.  Try/except around TestMe procedure doesn't trap it either.

Relevant? (from https://www.freepascal.org/docs-html/rtl/system/high.html):
"The return type is always the same type as the type of the argument (This can lead to some nasty surprises !)."

UNRELATED...On the IDE "pause" during debugging problem I had, I did a very simple project (not my big multi-threaded one).  Use the little project, an IDE "Pause" successfully stops the debugger as it did in gdb.  So I can have a "forever loop" in the source code, and hitting "pause" takes me to a stop in the source code within the loop as expected.  Even while in the windows event loop (not executing my source code since waiting for a button click), even though "pause" can't find a source line (as expected), I can hit run/f9 and things start up again as expected.

So I suspect my debug "pause" problem may be that my big project is multi-threaded and perhaps the lldb code doesn't know the threadid (perhaps like in the earlier "step" issue?) to successfully pause in the source code.  I believe gdb handled this -- but I will verify.
UPDATE: gdb does NOT pause successfully in my multi-threaded program either!  (Tested both 32 bit/carbon and 64 bit/cocoa)
« Last Edit: February 07, 2019, 09:05:51 pm by kcandrews »

 

TinyPortal © 2005-2018