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
> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> Some more info: I've stopped lldb (with the system lldb) when "
> Process::SetExitStatus (status=-1 (0xffffffff), description="Error 1")" is
> logged and gathered some more information.
> Is it possible that some packet types are not implemented?
>
> * frame #0: 0x00007fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x00007fff59a00bf1 libsystem_pthread.dylib`pthread_kill + 284
> frame #2: 0x00007fff598af6a6 libsystem_c.dylib`abort + 127
> frame #3: 0x00007fff5987820d libsystem_c.dylib`__assert_rtn + 324
> frame #4: 0x000000010b393539
> liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x00007fcfaa470218,
> status=-1, cstr="Error 1") at Process.cpp:1149:3
> frame #5: 0x000000010bbd1792
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x00007fcfaa470218)
> at ProcessGDBRemote.cpp:3877:28
> frame #6: 0x000000010b08f87b
> liblldb.10.0.99svn.dylib`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x00007fcfab218740)
> at HostNativeThreadBase.cpp:69:10
> frame #7: 0x0000000112be72fd
> liblldb.10.0.99svn.dylib`lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(arg=0x00007fcfab218740)
> at HostThreadMacOSX.mm:68:10
> frame #8: 0x00007fff599fe2eb libsystem_pthread.dylib`_pthread_body + 126
> frame #9: 0x00007fff59a01249 libsystem_pthread.dylib`_pthread_start + 66
> frame #10: 0x00007fff599fd40d libsystem_pthread.dylib`thread_start + 13
> (lldb) frame select 5
> frame #5: 0x000000010bbd1792
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x00007fcfaa470218)
> at ProcessGDBRemote.cpp:3877:28
> 3874 "System Integrity
> Protection");
> 3875 } else if (::strstr(continue_cstr, "vAttach") !=
> nullptr &&
> 3876 response.GetStatus().Fail()) {
> -> 3877 process->SetExitStatus(-1,
> response.GetStatus().AsCString());
> 3878 } else {
> 3879 process->SetExitStatus(-1, "lost connection");
> 3880 }
> (lldb) p response.GetError()
> (uint8_t) $0 = '\x01'
> (lldb) p response.GetServerPacketType()
> (StringExtractorGDBRemote::ServerPacketType) $1 =
> eServerPacketType_unimplemented
> (lldb) p response.GetResponseType()
> (StringExtractorGDBRemote::ResponseType) $2 = eError
> (lldb) p response.IsUnsupportedResponse()
> (bool) $3 = false
> (lldb) p response.GetStatus()
> (lldb_private::Status) $4 = (m_code = 1, m_type = eErrorTypeGeneric, m_string
> = "Error 1")
>
>
> Thanks,
> Gabor
>
> On Mon, Jul 22, 2019 at 4:59 PM Gábor Márton <martongab...@gmail.com
> <mailto:martongab...@gmail.com>> wrote:
> 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'
> HandleCommand, (revised) command_string: 'process launch -X true --'
> HandleCommand, wants_raw_input:'False'
> HandleCommand, command line after removing command name(s): '-X true --'
> Target::Launch() called for /Users/egbomrt/a.out
> Target::Launch the process instance doesn't currently exist.
> have platform=true, platform_sp->IsHost()=true, default_to_use_pty=true
> at least one of stdin/stdout/stderr was not set, evaluating default handling
> target stdin='(empty)', target stdout='(empty)', stderr='(empty)'
> Generating a pty to use for stdin/out/err
> Target::Launch asking the platform to debug the process
> Host::StartMonitoringChildProcess (callback, pid=94887, monitor_signals=0)
> source = 0x7f9bb923ec10
>
> ::waitpid (pid = 94887, &status, 0) => pid = 94887, status = 0x00000000
> (EXITED), signal = 0, exit_status = 0
> Host::StartMonitoringChildProcess (callback, pid=94888, monitor_signals=0)
> source = 0x7f9bb9218180
>
> Went to stop the private state thread, but it was already invalid.
> Process::SetPublicState (state = attaching, restarted = 0)
> Host::StartMonitoringChildProcess (callback, pid=94889, monitor_signals=0)
> source = 0x7f9bb9243bd0
>
> thread created
> Process::AttachCompletionHandler::AttachCompletionHandler
> process=0x7f9bb8803c18, exec_count=0
> Process::ControlPrivateStateThread (signal = 4)
> Sending control event of type: 4.
> thread created
> Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) thread
> starting...
> timeout = <infinite>, event_sp)...
> Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) got a
> control event: 4
> timeout = <infinite>, event_sp)...
> timeout = <infinite>
> timeout = <infinite>, event_sp)...
> thread created
> Process::SetExitStatus (status=-1 (0xffffffff), description="Error 1")
> Process::SetPrivateState (exited)
> Process::SetPrivateState (exited) stop_id = 1
> Process::AttachCompletionHandler::PerformAction called with state exited (10)
> Ran next event action, result was 2.
> Process::ShouldBroadcastEvent (0x7f9bb92423b0) => new state: exited, last
> broadcast state: exited - YES
> Process::HandlePrivateEvent (pid = 94888) broadcasting new state exited (old
> state attaching) to hijacked
> Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) about to
> exit with internal state exited...
> Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) thread
> exiting...
> Process::SetPublicState (state = exited, restarted = 0)
> timeout = <infinite>, event_sp) => exited
> HandleCommand, command did not succeed
> error: process exited with status -1 (Error 1)
> (lldb) ::waitpid (pid = 94889, &status, 0) => pid = 94889, status =
> 0x00000000 (EXITED), signal = 0, exit_status = 0
> (lldb)
>
> On Mon, Jul 22, 2019 at 4:44 PM Stefan Gränitz <stefan.graen...@gmail.com
> <mailto:stefan.graen...@gmail.com>> wrote:
> 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 Integrity Protection status: disabled.
>> 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) r
>> error: process exited with status -1 (Error 1)
>> (lldb) ^D
>> egbomrt@msmarple ~/llvm2/build/release_assert $ ls -la ~/a.out
>> -rwxr-xr-x 1 egbomrt admin 8736 Júl 22 16:16 /Users/egbomrt/a.out
>> egbomrt@msmarple ~/llvm2/build/release_assert $
>> ```
>>
>> On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz <stefan.graen...@gmail.com
>> <mailto:stefan.graen...@gmail.com>> wrote:
>>> 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 system binaries, you may need to disable SIP.
>>
>> On 22/07/2019 16:14, Gábor Márton wrote:
>>> 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 build dir) I have the debugserver signed:
>>> ```
>>> $ codesign -dvvvv ~/llvm2/build/release_assert/bin/debugserver
>>> Executable=/Users/egbomrt/llvm2/build/release_assert/bin/debugserver
>>> Identifier=com.apple.debugserver
>>> Format=Mach-O thin (x86_64)
>>> CodeDirectory v=20100 size=38534 flags=0x0(none) hashes=1197+5
>>> location=embedded
>>> VersionPlatform=1
>>> VersionMin=658944
>>> VersionSDK=658944
>>> Hash type=sha256 size=32
>>> CandidateCDHash sha256=7b475cfa7127c84281ceb206093d13dd464dad74
>>> Hash choices=sha256
>>> Page size=4096
>>> CDHash=7b475cfa7127c84281ceb206093d13dd464dad74
>>> Signature size=1611
>>> Authority=lldb_codesign
>>> Signed Time=2019. Jul 22. 15:26:29
>>> Info.plist entries=6
>>> TeamIdentifier=not set
>>> Sealed Resources=none
>>> Internal requirements count=1 size=100
>>> $
>>> ```
>>>
>>> So far so good.
>>> But then when I try to use lldb I have permission problems:
>>> ```
>>> 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)
>>> (lldb) ^D
>>> egbomrt@msmarple ~/llvm2/build/release_assert $
>>> ```
>>>
>>> However, as root I can use lldb:
>>> ```
>>> egbomrt@msmarple ~/llvm2/build/release_assert $ sudo ./bin/lldb /bin/ls
>>> (lldb) target create "/bin/ls"
>>> Current executable set to '/bin/ls' (x86_64).
>>> (lldb) r
>>> Process 28052 launched: '/bin/ls' (x86_64)
>>> .ninja_deps compile_commands.json
>>> .ninja_log docs
>>> CMakeCache.txt examples
>>> CMakeDoxyfile.in include
>>> ...
>>> Process 28052 exited with status = 0 (0x00000000)
>>> (lldb) ^D
>>> egbomrt@msmarple ~/llvm2/build/release_assert $
>>> ```
>>>
>>> Is it possible to codesign in a way that a regular user can run the built
>>> debugserver? Or what else could be the reason behind this permission
>>> problem?
>>>
>>> Thanks,
>>> Gabor
>>>
>>> On Fri, Jul 19, 2019 at 11:47 PM Stefan Gränitz <stefan.graen...@gmail.com
>>> <mailto:stefan.graen...@gmail.com>> wrote:
>>> 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 happens again (or to anyone else), a clean build seems to be a good
>>> first step.
>>>
>>> Best,
>>> Stefan
>>>
>>> On 19/07/2019 19:36, Gábor Márton wrote:
>>>
>>>> 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 <martongab...@gmail.com
>>>> <mailto:martongab...@gmail.com>> wrote:
>>>> 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/DevToolsSecurity --enable".
>>>>
>>>> On Fri, Jul 19, 2019 at 4:46 PM Gábor Márton <martongab...@gmail.com
>>>> <mailto:martongab...@gmail.com>> wrote:
>>>> 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 with status -1 (Error 1)
>>>> ```
>>>>
>>>> I do set up "-DLLDB_USE_SYSTEM_DEBUGSERVER=ON" with cmake so I see
>>>> ```
>>>> -- LLDB tests use out-of-tree debugserver:
>>>> /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver
>>>> ```
>>>>
>>>> Also, I have inspected the following test output
>>>> ```
>>>> Command invoked: /usr/bin/python
>>>> /Users/egbomrt/llvm2/git/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
>>>> -s /Users/egbomrt/llvm2/build/release_assert/lldb-test-traces --build-dir
>>>> /Users/egbomrt/llvm2/build/release_assert/lldb-test-build.noindex -S nm -u
>>>> CXXFLAGS -u CFLAGS --executable
>>>> /Users/egbomrt/llvm2/build/release_assert/./bin/lldb --dsymutil
>>>> /Users/egbomrt/llvm2/build/release_assert/./bin/dsymutil --filecheck
>>>> /Users/egbomrt/llvm2/build/release_assert/./bin/FileCheck -C
>>>> /Users/egbomrt/llvm2/build/release_assert/bin/clang --codesign-identity -
>>>> --out-of-tree-debugserver --arch x86_64 -t --env TERM=vt100 -p
>>>> TestCModules.py --results-port 49931 -S nm --inferior -p TestCModules.py
>>>> /Users/egbomrt/llvm2/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/modules
>>>> --event-add-entries worker_index=0:int
>>>> 1 out of 736 test suites processed - TestCModules.py
>>>> ```
>>>> so it seems like the argument for --out-of-tree-debugserver is missing...
>>>>
>>>> Could you please advise?
>>>>
>>>> Thank you,
>>>> Gabor
>>> --
>>> https://flowcrypt.com/pub/stefan.graen...@gmail.com
>>> <https://flowcrypt.com/pub/stefan.graen...@gmail.com>--
>> https://flowcrypt.com/pub/stefan.graen...@gmail.com
>> <https://flowcrypt.com/pub/stefan.graen...@gmail.com>--
> https://flowcrypt.com/pub/stefan.graen...@gmail.com
> <https://flowcrypt.com/pub/stefan.graen...@gmail.com>_______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
