Forum > Debugger

Xcode Command Line Tools 15 Breaks lldb (macOS Ventura 13.6/Sonoma 14.0 ARM64)

(1/6) > >>

msintle:
Has anyone else seen this?

Might be worth mentioning the Messages window contains the following errors after a build, which starts happening only after Xcode Command Line Tools 15 are installed:

Error: ld: warning: -multiply_defined is obsolete
Error: -macosx_version_min has been renamed to -macos_version_min
Error: ld: warning: ignoring duplicate libraries: '-lc'
Error: ld: warning: no platform load command found in '/Users/c/Developer/miamp/lib/x86_64-darwin/miamp.or', assuming: macOS

Debugging doesn't seem to work properly anymore and hangs, for example, the moment I display a secondary window. It happens only on one particular secondary window. The Lazarus IDE Debug Output window indicated an error of the sort <"\" is not a valid boolean>, after which my process was terminated automatically.

Please note that there is no error with the code here, at least with code that I have written - it worked fine (and debugged fine) without this error immediately before my upgrade to Xcode Command Line Tools 15. Maybe the fact that I'm sharing the project between Lazarus 2.2.6 and Lazarus "3.9.9" installed by the latest FPCUPDELUXE trunk/Free Pascal 3.3.1 could have been an issue, but again, I had no problems debugging with that combination either before my upgrade to Xcode Command Line Tools 15.

So anyways, the plot thickens. I went ahead and set a breakpoint in the function where the problematic secondary window is shown. Guess what, now lldb moves, but barely just inching along. After a few lines into the function, a spinning and stuttering beachball taking ages. I'll paste the entire Debug Output window, as the log may speak for itself?

(please see attachment as the log is too big to paste here)

Finally, the same crash happens on a line where I call TryStrToInt. No backslash conversion attempted into a boolean at all. Go figure? Can't be an LCL form streaming incompatibility issue either, can it?

I also built gdb from Homebrew and signed and tried debugging with that. Fares even worse, doesn't even start the app at all. Just hangs where the attached log ends.

(again please see the attachment)

With gdb consuming 0% CPU and the app not showing at all in the Activity Monitor.

Martin_fr:
First of all, is your Computer intel based? Or at least: Is that code compiled for Intel 64bit (and maybe run in emulation)?
Because it tries to access the register "RDI" (which is intel 64 bit)

About "is not a valid boolean"

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---(lldb) process continueProcess 38234 resuming(lldb)    p/x $rdi(unsigned long) 0x000000010f4c3780(lldb)    p/x $rdx(unsigned long) 0x0000000305989850(lldb)    p ((char ***)$rdi)[0][3](char *) 0x000000010082de38 "\rEConvertError"(lldb)    p ((char **)$rdi)[1](char *) 0x0000000111246cd8 "\"\" is not a valid boolean."Process 38234 stopped* thread #1: tid=0x1fdf0f: 0x0000000100017010, 0x0000000305989828, 0x0000000305989850 &&//FULL:    &&//SHORT:    &&//LINE:    &&//MOD: miamp &&//FUNC: FPC_RAISEEXCEPTION <<&&//FRAME, stop reason = breakpoint 3.1...Process 38234 stopped* thread #1: tid=0x1fdf0f: 0x0000000100017010, 0x0000000305989828, 0x0000000305989850 &&//FULL:    &&//SHORT:    &&//LINE:    &&//MOD: miamp &&//FUNC: FPC_RAISEEXCEPTION <<&&//FRAME, stop reason = breakpoint 3.1        frame #0: 0x0000000100017010, 0x0000000305989828, 0x0000000305989850 &&//FULL:    &&//SHORT:    &&//LINE:    &&//MOD: miamp &&//FUNC: FPC_RAISEEXCEPTION <<&&//FRAMETarget 0: (miamp) stopped.
So your app raised an exception, LLDB correctly halts on the breakpoint (in FPC_RAISEEXCEPTION).

The breakpoints has some commands to automatically execute. Those are to get the exception message, etc.


--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---p ((char **)$rdi)[1]Should cast the RDI register to ppchar, deref it once, and get the exception message.

Your exception is of class EConvertError, and has the message
   "" is not a valid boolean.


Up to this point everything is exactly as expected....
Though, what I haven't checked is if the syntax used by lldb is "as expected" => that is maybe some keyword changed, and the IDE does not recognise the output...

So what happens at that point in the IDE?

Since an exception was raised, It would be expected that the IDE displays a popup saying something about that exception, and offering to either "break" or "continue".
Does it?

Martin_fr:
I think I can see what happens. lldb prints the result as

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---(lldb)    p ((char ***)$rdi)[0][3]
But the IDE expects a "=" in that line.
So lldb changed its output.

Martin_fr:
Please ASAP test the following patch

--- Code: Diff  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---diff --git a/components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas b/components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pasindex 44853e1dd6..462211109d 100644--- a/components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas+++ b/components/lazdebuggers/lazdebuggerlldb/lldbinstructions.pas@@ -1113,6 +1113,15 @@ function TLldbInstructionExpressionBase.ProcessInputFromDbg(const AData: String     if ParseStruct(found[2]) then       SetContentReceieved;     exit;+  end+  else+  // (char *) 0x0000000111246cd8 "\"\" is not a valid boolean."+  if StrMatches(AData, ['(', ') 0x', ' ', ''], found) then begin+    FRes := AData;+    FCurly := 0;+    if ParseStruct(found[2]) then+      SetContentReceieved;+    exit;   end; // error: use of undeclared identifier 'i' // (int) $0 = 133 
Otherwise it could miss the deadline for RC2

msintle:

--- Quote from: Martin_fr on October 06, 2023, 05:52:43 pm ---First of all, is your Computer intel based? Or at least: Is that code compiled for Intel 64bit (and maybe run in emulation)?
Because it tries to access the register "RDI" (which is intel 64 bit)

--- End quote ---

That is correct, running the Lazarus 2.2.6 Intel version installed from the official PKG/DMG downloads on Apple Silicon through emulation.

Please note that I have never been able to get a recent FPCUPDELUXE based installation of Lazarus "3.9.9" for native Apple Silicon working with debugging, where recent is the last 6-9 months (although it may have worked at some point before that, if I vaguely remember correctly).


--- Quote from: Martin_fr on October 06, 2023, 05:52:43 pm ---Your exception is of class EConvertError, and has the message
   "" is not a valid boolean.

--- End quote ---

As shocking as it is, that is entirely incorrect. The code I am stepping through has nothing to do with boolean conversions, as I already explained above. I do have one TryStrToInt call, which is designed to be safe to use with any value to begin with.


--- Quote from: Martin_fr on October 06, 2023, 05:52:43 pm ---Since an exception was raised, It would be expected that the IDE displays a popup saying something about that exception, and offering to either "break" or "continue".
Does it?

--- End quote ---

That doesn't happen as you've already gathered, what happens instead is an infinitely spinning beachball and very brief breaks where the IDE seems momentarily responsive before going back to the beachball - and/or termination of the process being debugged and/or other inconsistencies.

Navigation

[0] Message Index

[#] Next page

Go to full version