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> 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>
> 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>
>> 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> 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>
>>>> 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>
>>>>> 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
>>
>>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
