Hi all,
I’m having some weird problems when testing lldb.
Most tests don’t stop the a.out file and leave it in an uninterruptible sleep.
This will exhaust the machine’s PID space and make it stop working.
Can you reproduce this?
I’m using lldb from trunk (updated a few minutes ago), and it happens the same way wether I compile it with the latest clang or clang from the latest Xcode.
I’m on Mountain Lion 10.8.2.
Regards,
Filipe
Hi Filipe,
Yes, I am seeing the same behaviour on Mac OS X Mountain Lion (10.8.2) here, but not on Linux. It was not introduced recently, as we've been seeing the behaviour for the last month or two, and also with Lion.
A workaround, though not a great one, is to invoke the tests with "sudo" then all the test inferior processes exit cleanly. I am not sure what the root-cause is.
Dan
Hi all,
I'm having some weird problems when testing lldb.
Most tests don't stop the a.out file and leave it in an uninterruptible sleep.
This will exhaust the machine's PID space and make it stop working.Can you reproduce this?
This happens when your code signing signature is bad.
Did you re-install your system? Upgrade your OS?
To fix this, open keychain access and search for lldb_codesign, remove all, reboot, then follow the code signing docs again.
Hi Filipe,
Yes, I am seeing the same behaviour on Mac OS X Mountain Lion (10.8.2) here, but not on Linux. It was not introduced recently, as we've been seeing the behaviour for the last month or two, and also with Lion.
A workaround, though not a great one, is to invoke the tests with "sudo" then all the test inferior processes exit cleanly. I am not sure what the root-cause is.
It is usually your "lldb_codesign" code signing cert going bad, expired, or no longer valid due to OS upgrade/reinstall.
But shouldn’t Xcode say anything?
I followed all the (weird) steps in the doc, but I will try again.
Thanks,
Filipe
Okay, now it seems like something is not right.
What should be signed? The lldb binary? debugserver?
I have this on debugserver:
± codesign -vvv tools/debugserver/build/Debug/debugserver
tools/debugserver/build/Debug/debugserver: valid on disk
tools/debugserver/build/Debug/debugserver: satisfies its Designated Requirement
The only other signed files are the XPC executables.
Thanks,
Filipe
Just because it says it code signed ok, doesn't mean it will run.
debugserver and the XPC shlibs are the only things that need to be codesigned.
Try running debugserver directly:
./LLDB.framework/Resources/debugserver localhost:1234 /bin/ls
debugserver-193 for x86_64.
Listening to port 1234...
If you see the "listening to port" message, it is working, else it isn't and it will complain.
Hmm, I have some problem here:
± ./LLDB.framework/Resources/debugserver localhost:1234 /bin/ls
debugserver-193 for x86_64.
error: failed to launch process ./LLDB.framework/Resources/debugserver: failed to get the task for process 64342
The problem is: I just deleted the certificate, and followed all the instructions again. Can 10.8.2 have changed anything?
Thanks,
Filipe
Hmm, I have some problem here:
± ./LLDB.framework/Resources/debugserver localhost:1234 /bin/ls
debugserver-193 for x86_64.
error: failed to launch process ./LLDB.framework/Resources/debugserver: failed to get the task for process 64342The problem is: I just deleted the certificate, and followed all the instructions again. Can 10.8.2 have changed anything?
Probably not.
- Delete all certs + public private key pairs.
- Reboot.
- remove ~/Desktop/lldb_codesign.cer, or you might get a ~/Desktop/lldb_codesign_1.cer when you drag your new lldb_codesign.cer to the desktop and cause the system to trust your old cert
- nuke any and all LLDB build folders (the kernel caches code signing failures and needs to see the inode go away for the file)
- follow instructions
- reboot
Working now??
It all works, now. I found that, for some reason, I ended up building debugserver on the BuildAndIntegration configuration, which wouldn’t work, as expected.
Thanks,
Filipe