> $ sudo /usr/sbin/DevToolsSecurity --enable
Unfortunately, this did not help.
Anyway, I've found the solution, but took a while.
So, the given scripts/macos-setup-codesign.sh adds a certificate to the
system keychain /Library/Keychains/System.keychain and with a TrustRoot
policy. This explains wh
I believe you can run a shell command as root:
$ sudo /usr/sbin/DevToolsSecurity --enable
Then you should be able to debug after that, even on ssh connections.
Greg
> On Jul 22, 2019, at 12:31 PM, Frédéric Riss via lldb-dev
> wrote:
>
>
>
>> On Jul 22, 2019, at 10:14 AM, Gábor Márton >
> On Jul 22, 2019, at 10:14 AM, Gábor Márton wrote:
>
> error 18:33:20.280017 +0200 authd Fatal: interaction not allowed (session
> has no ui access) (engine 3727)
> This gave me a hint, so I used VPN to have a gui and got a gui window popped
> up to authenticate lldb. And then I could ru
*error 18:33:20.280017 +0200 authd Fatal: interaction not allowed (session
has no ui access) (engine 3727)*
This gave me a hint, so I used VPN to have a gui and got a gui window
popped up to authenticate lldb. And then I could run lldb as a normal user.
Hurray!
BUT through ssh I still cannot run l
Ok, I've done that, here are the logs which happen before the first
debugserver error:
error 18:33:20.236506 +0200 taskgated cannot open file at line 42270 of
[95fbac39ba]
error 18:33:20.236526 +0200 taskgated os_unix.c:42270: (2)
open(/var/db/DetachedSignatures) - No such file or directory
defaul
I think the system logs (in Console.app) would tell us more. Search for
debugserver and you should find attach failures. Then remove the filter and
look at what happens right before that. There should be a log from taskgated or
authd that is a little more explicit about what’s failing.
Fred
>
Some more info: I've stopped lldb (with the system lldb) when
" Process::SetExitStatus (status=-1 (0x), description="Error 1")"
is logged and gathered some more information.
Is it possible that some packet types are not implemented?
* frame #0: 0x7fff599452c6 libsystem_kernel.dylib`_
Yes, here it is.
egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
(lldb) target create "/Users/egbomrt/a.out"
Current executable set to '/Users/egbomrt/a.out' (x86_64).
(lldb) log enable lldb default
(lldb) r
Processing command: r
HandleCommand, cmd_obj : 'process launch'
Hand
Interesting. Is there any extra info dumped to the log (e.g. `log enable
lldb default`)
On 22/07/2019 16:34, Gábor Márton wrote:
> Well, SIP is turned off and I experience the same with a binary I just
> built:
> ```
> egbomrt@msmarple ~/llvm2/build/release_assert $ csrutil status
> System Integri
Well, SIP is turned off and I experience the same with a binary I just
built:
```
egbomrt@msmarple ~/llvm2/build/release_assert $ csrutil status
System Integrity Protection status: disabled.
egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
(lldb) target create "/Users/egbomrt/a.ou
> egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) r
> *error: process exited with status -1 (Error 1)*
I don't think this is related to debugserver codesigning. If you really
need to debug s
I am still struggling with this issue. Now I decided to work with the
codesigned version of the debugserver, becasue I had an error when I tried
to use the system debugserver.
So I've run scripts/macos-setup-codesign.sh
After a reboot and fresh build (I have removed the CMakeCache.txt and the
whole
Hi Gábor, I am sorry this caused an issue for you. Good that apparently
it's resolved now.
Did you reconfigure an existing build-tree? Your observations would make
sense in this context, because the change affects CMake cached
variables. This is unfortunate, but can not always be avoided. If this
I this was because of a change in llvm which broke codesigning of
debugserver: https://reviews.llvm.org/D64965
On Fri, Jul 19, 2019 at 10:36 AM Gábor Márton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Actually, it is embarrassing (perhaps for macOS and not for me) that after
> a reboot the p
Actually, it is embarrassing (perhaps for macOS and not for me) that after
a reboot the problem is gone.
Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a reboot is
required, but could not find anything official about that.
On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton wrote:
> This migh
This might not be related to the debugserver, I just realized that I get
"error: process exited with status -1 (Error 1)"
even with the simplest main.c.
This may be some kind of security issue on mac OS...
Though I've checked and I have SIP disabled and I have executed "sudo
/usr/sbin/DevToolsSecur
Hi Stefan,
Since the commit
"[CMake] Always build debugserver on Darwin and allow tests to use the
system's one"
I cannot use the system debugserver for testing.
I receive the following error message from lldb when I execute "ninja
check-lldb":
```
runCmd: run
runCmd failed!
error: process exited
17 matches
Mail list logo