Bug 263387

Looks like these commands are actually run _inside_ lldb, with the relevant qtcreator code in src/plugins/debugger/lldb/lldbengine.cpp:

>    executeCommand("script sys.path.insert(1, '" + rp.dumperPath.path().toLocal8Bit() + "')");
>    // This triggers reportState("enginesetupok") or "enginesetupfailed":
>    executeCommand("script from lldbbridge import *");

lldb gained support for lua scripting in recent versions, even though python is probably still default. There is a CLI argument (-l or --script-language) to choose the language, but I don't see it used in qtcreator sources.

@Ivan: Can you double check in the debugger logs that qtcreator uses lldb13 or lldb14 from ports, something like:

> STARTING LLDB: /usr/local/bin/lldb14

At least on 13.0-RELEASE lldb in base defaults to lua scripts...

> ~> /usr/bin/lldb
> (lldb) script sys.path.insert(1, '/usr/local/share/qtcreator/debugger/')
> error: lua failed attempting to evaluate 'sys.path.insert(1, '/usr/local/share/qtcreator/debugger/')': [string "buffer"]:1: attempt to index a nil value (global 'sys')

...whereas lldb13 from ports defaults to python:

> ~> /usr/local/bin/lldb13
> (lldb) script sys.path.insert(1, '/usr/local/share/qtcreator/debugger/')
> (lldb) script sys.path
> ['/usr/local/llvm13/lib', '/usr/local/share/qtcreator/debugger/', '/usr/local/llvm13/lib/python3.8/site-packages', '/usr/local/lib/python38.zip', '/usr/local/lib/python3.8', '/usr/local/lib/python3.8/lib-dynload', '/usr/local/lib/python3.8/site-packages', '.']

>@Ivan: Can you double check in the debugger logs that qtcreator uses lldb13 or lldb14 from ports, something like:

>> STARTING LLDB: /usr/local/bin/lldb14

For lldb13 I use the default lldb binary:

STARTING LLDB: /usr/bin/lldb

❯ /usr/bin/lldb --version
lldb version 13.0.0 (git@github.com:llvm/llvm-project.git revision llvmorg-13.0.0-0-gd7b669b3a303)
  clang revision llvmorg-13.0.0-0-gd7b669b3a303
  llvm revision llvmorg-13.0.0-0-gd7b669b3a303


And then I switch to lldb14 I use this binary:

dSTARTING LLDB: /usr/local/bin/lldb14

❯ /usr/local/bin/lldb14 --version
lldb version 14.0.1



All the packages were installed via pkg install. No custom builds from ports.

I also noticed that lldb14 error output is slightly different:

>(lldb) script theDumper.executeDebuggerCommand({"command":"settings append target.source-map /home/qt/work/qt /usr/local/include/../Src","token":2})
>@
>token("2")@
>@
>success="0",output="",error="error: the replacement path doesn't exist: \"/usr/local/include/../Src\"\n"@

I have no idea what are that paths. I don't have neither /home/qt/work/qt nor /usr/local/include/../Src.

> For lldb13 I use the default lldb binary:
> 
> STARTING LLDB: /usr/bin/lldb

This is the one installed with the FreeBSD base system. It will not work here AFAIK, because it is stripped down and missing the Python script bindings. You'll have to "pkg install llvm13" and configure /usr/local/bin/lldb13 in qtcreator.

Your use of lldb14 looks ok though - are you sure it doesn't work? What are the symptoms?

I also get the error message about /usr/local/include/../Src, but debugging still works for me.

>Your use of lldb14 looks ok though - are you sure it doesn't work? What are the symptoms?

The symptoms are:
The application immediately quit after you run it.


Application output:

21:52:52: Debugging /path/to/the/app ...
got fallback qt version 0x5020021:52:56: Debugging of /path/to/the/app has finished.


A bit more from debugger log:

>@
>result={token="9",success="1",msg="success",exe="/path/to/the/app"}@
>9^
<11executeRoundtrip({"token":11})
>(lldb) script theDumper.setFallbackQtVersion({"token":10,"version":328192})
>@
>bridgemessage={msg="got fallback qt version 0x50200",channel="10"}
>@
>(lldb) script theDumper.executeRoundtrip({"token":11})
 got fallback qt version 0x50200
>@
>result={token="11",}@
>11^
dNOTE: ENGINE SETUP OK
dState changed from EngineSetupRequested(1) to EngineRunRequested(3)
dCALL: RUN ENGINE
 Running requested...
<12runEngine({"token":12})
>(lldb) script theDumper.runEngine({"token":12})
>@
>success="0",error={type="1",status="'A' packet returned an error: 8",code="4294967295",desc="error: 'A' packet returned an error: 8"}@
>@
>state="enginerunfailed"@
dNOTE: ENGINE RUN FAILED
 Run failed.
dState changed from EngineRunRequested(3) to EngineRunFailed(4)
dState changed from EngineRunFailed(4) to EngineShutdownRequested(14)
dCALL: SHUTDOWN ENGINE
dQUIT DEBUGGER REQUESTED IN STATE 14
dLLDB PROCESS ERROR: 1
dNOTE: ENGINE SHUTDOWN FINISHED
dState changed from EngineShutdownRequested(14) to EngineShutdownFinished(15)
 Debugger finished.
dState changed from EngineShutdownFinished(15) to DebuggerFinished(16)

That's quite a different error. Does manual debbugging using lldb14 in a terminal work?

Searching for the error message online hints at a permission error, maybe a System Hardening setting or user permissions.

> Searching for the error message online hints at a permission error, maybe a System Hardening setting or user permissions.

Ok. Thank you for the support.

I googled it one more time and yes. You were right.

This line helped:
sysctl security.bsd.unprivileged_proc_debug=1