[lldb-dev] lldb-114: initial process state wasn't stopped

[Jim Ingham]

This does look like a problem with debugserver unable to get task_for_pid rights, which either means your code signing cert is not trusted by you or it has lost the magic necessary to be recognized by the system.  Make sure your lldb_codesign cert is still trusted (in Keychain Access it should have a blue +, not a red x...  But this process seems a little flakey.  Sometimes when you restart magically the code signing magically starts to be recognized.  Sometimes you have to delete your code signing cert (remember to remove it from the login & system keychains) then re-make it following the instructions in the doc/code-signing.txt.

Jim

On Feb 17, 2012, at 2:55 PM, Filipe Cabecinhas wrote:

> Hi all, 
> 
> I have some more information. It seems the problem may be with debugserver, somewhere.
> 
> When running a program with Apple's latest lldb (from the command line tools package, for Xcode 4.3), I get:
> -----------------------------------------------
> 
> [~]% xcodebuild -version
> Xcode 4.3
> Build version 4E109
> [~]% lldb --version
> LLDB-112
> 
> 
> [~]% lldb ./tests
> (lldb) log enable gdb-remote all
> (lldb) run
> 
> 
> 
> (snip)
> 
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () sending continue packet: vAttach;221f
> <lldb.process.gdb-remote.async> send packet: $vAttach;221f#00
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () WaitForPacket(vAttach;221f)
> <lldb.process.gdb-remote.async> size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xffffffff, status = success, error = (null)) => bytes_read = 270
> <lldb.process.gdb-remote.async> read packet: $T11thread:1f03;qaddr:a0;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:e0f6bf5fff7f0000;08:0000000000000000;09:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;metype:5;mecount:2;medata:10003;medata:11;#00
> 
> 
> 
> -----------------------------------------------
> 
> With the lldb I built, I get:
> -----------------------------------------------
> 
> [~]% ./dev/lldb/build/Debug/lldb --version
> LLDB-115
> 
> 
> [~]% ./dev/lldb/build/Debug/lldb ./tests
> (lldb) log enable gdb-remote all
> (lldb) run
> 
> 
> 
> (snip)
> 
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () sending continue packet: vAttach;2265
> <lldb.process.gdb-remote.async> send packet: $vAttach;2265#00
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () WaitForPacket(vAttach;2265)
> <lldb.process.gdb-remote.async> size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xffffffff, status = success, error = (null)) => bytes_read = 7
> <lldb.process.gdb-remote.async> read packet: $E01#00
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () got packet: E01
> <lldb.process.gdb-remote.async> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () => invalid
> 
> 
> -----------------------------------------------
> 
> 
> Codesign seems to say it's okay:
> -----------------------------------------------
> 
> [~]% codesign -d -vv ./dev/lldb/tools/debugserver/build/Debug/debugserver
> Executable=/Users/filcab/dev/lldb/tools/debugserver/build/Debug/debugserver
> Identifier=com.apple.${PRODUCT_NAME:rfc1034identifier}
> Format=Mach-O universal (i386 x86_64)
> CodeDirectory v=20100 size=5992 flags=0x0(none) hashes=293+2 location=embedded
> Signature size=1382
> Authority=lldb_codesign
> Signed Time=Feb 17, 2012 4:18:45 PM
> Info.plist entries=6
> Sealed Resources=none
> Internal requirements count=1 size=136
> 
> 
> [~]% codesign -vv ./dev/lldb/tools/debugserver/build/Debug/debugserver
> ./dev/lldb/tools/debugserver/build/Debug/debugserver: valid on disk
> ./dev/lldb/tools/debugserver/build/Debug/debugserver: satisfies its Designated Requirement
> 
> 
> -----------------------------------------------
> 
> 
> Any clues on what's happening? I will now try to debug debug server and see where the problem may be, but this may be a known issue.
> 
> Regards,
> 
>  Filipe
> 
> 
> On Friday, February 17, 2012 at 4:31 PM, Filipe Cabecinhas wrote:
> 
>> Hi.
>> 
>> I have the same problem with the latest HEAD from svn. I asked yesterday about the python bindings, but the problem is not from that. I have the lldb_codesign certificate with "always trust" for code signing.
>> 
>> Regards, 
>> 
>> Filipe
>> 
>> 
>> On Friday, February 17, 2012 at 1:32 PM, Andrey Zaytsev wrote:
>> 
>>> Hello. 
>>> Here is what i get trying to debug anything:
>>> 
>>> ~/Projects/ULTIMATE (git::master)$ /Applications/Xcode.app/Contents/Developer/usr/bin/lldb 
>>> (lldb) file /Users/zajac/Projects/ULTIMATE/system/DerivedData/debug-42b46838/Build/Products/macos-target-debug/macos-target
>>> Current executable set to '/Users/zajac/Projects/ULTIMATE/system/DerivedData/debug-42b46838/Build/Products/macos-target-debug/macos-target' (x86_64).
>>> (lldb) r
>>> Process 26225 launched: '/Users/zajac/Projects/ULTIMATE/system/DerivedData/debug-42b46838/Build/Products/macos-target-debug/macos-target' (x86_64)
>>> error: initial process state wasn't stopped: exited
>>> (lldb) 
>>> 
>>> But remote-debug on device works fine. Wierd.
>>> 
>>> lldb-114 from Xcode 4.4
>>> Mac OS X Lion 10.7.3
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu (mailto:lldb-dev at cs.uiuc.edu)
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
> 
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev