[lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

[Tony Perrie via lldb-dev]

I can only seem to debug our binary as the root user om 10.11.  I rebooted
at one point, and lldb did work briefly with a system user but then after
the machine ran for a bit, it proceeded to not work again.  Rebooted again,
and again, lldb failes with this error...

lldb /opt/aspera/bin/ascp
(lldb) target create "/opt/aspera/bin/ascp"
2015-10-02 14:24:17.091 lldb[1721:12884] Metadata.framework [Error]:
couldn't get the client port
Current executable set to '/opt/aspera/bin/ascp' (x86_64).
(lldb) r -i ~/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
error: process exited with status -1 (unable to attach)

As root, I can reproduce the error:

root# lldb /opt/aspera/bin/ascp
(lldb) target create "/opt/aspera/bin/ascp"
2015-10-02 14:30:40.515 lldb[1864:14630] Metadata.framework [Error]:
couldn't get the client port
Current executable set to '/opt/aspera/bin/ascp' (x86_64).
(lldb) r -i /var/root/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
Process 1866 launched: '/opt/aspera/bin/ascp' (x86_64)

Session Stop  (Error: Session initiation failed, Server process failed to
start: permissions?)
Process 1866 exited with status = 1 (0x0001)

I have another machine running OS X 10.9 and lldb where everything works
flawlessly.

The problem with out binary seems to be that OS X is prohibiting our binary
from starting another process (even as root).  Not sure if this is the
right list for that question though.  Assume it's something to do with
10.11's security model.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Too many open files

[Todd Fiala via lldb-dev]

(swapped out the lldb list for the newer one)

On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala  wrote:

> Hmm, sounds suspicious.
>
> Can you try running the tests with two options and see if you get
> different results?
>
> # should be equivalent for the default on Windows, thus should match your
> above results.  This one uses a thread per worker queue.
> --test-runner-name threading-pool
>
> # should use a different test runner.  This one uses a process per worker
> queue.
> --test-runner-name multiprocessing-pool
>
> Aside from that, it seems like the total number of open files is exceeding
> some process/system maximum, which sounds like (maybe) we're leaking files
> somewhere.  Not enough info yet to guess where that might be coming in
> from, but maybe a part of the test runner isn't closing files somewhere.
>
> The other thing you can try is reducing the total number of threads, with:
> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>
> in the event that your machine has a mongo number of logical cores, and
> perhaps it is trying to do too much.  (In that case, the
> multiprocessing-pool runner might actually help).
>
> Thanks!
>
> -Todd
>
> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
> wrote:
>
>> When running LLDB tests on Windows, I started getting a "too many open
>> files" error from Python.  I used git bisect to narrow it down to this
>> revision:
>>
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>
>> The error output is:
>>
>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>> --event-add-entries worker_index=7:int
>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>   Traceback (most recent call last):
>>   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
>> 
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
>> walk_and_invoke
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in 
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
>> threading_test_runner_pool
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
>> map_async_run_loop
>>   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558, in get
>> OSError: [Errno 24] Too many open files
>> [77809 refs]
>> ninja: build stopped: subcommand failed.
>>
>>
>> Any clue what might have caused this or what can be done to fix it?
>>
>> It's Friday afternoon, so there's no urgency from my perspective.  I'll
>> probably get back to this on Monday morning.
>>
>> Thanks,
>> Adrian McCarthy
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

[Todd Fiala via lldb-dev]

Hi Tony,

This is the right list.

Are you using an LLDB that you built locally?  If so, can you move aside
the debugserver that you find somewhere under in your LLDB.framework bundle
directory, and make a symlink to the debugserver that comes out of your
/Applications/Xcode.app bundle?  Your official Xcode.app one should be in a
location like:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver

The other thing it could be is that I think your lldb_codesign cert may
need to be recreated on a new OS.  I seem to recall the instructions there
indicate the code signing cert does not survive OS updates but I might be
mistaken.

I suspect the symlink will resolve your issue, though.  With tighter
security, it is likely that a home-built debugserver is no longer going to
work without being Apple signed.  We may need to adjust the Xcode build to
create a symlink to the official one if that's the case.

-Todd

On Fri, Oct 2, 2015 at 2:35 PM, Tony Perrie via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I can only seem to debug our binary as the root user om 10.11.  I rebooted
> at one point, and lldb did work briefly with a system user but then after
> the machine ran for a bit, it proceeded to not work again.  Rebooted again,
> and again, lldb failes with this error...
>
> lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:24:17.091 lldb[1721:12884] Metadata.framework [Error]:
> couldn't get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i ~/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> error: process exited with status -1 (unable to attach)
>
> As root, I can reproduce the error:
>
> root# lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:30:40.515 lldb[1864:14630] Metadata.framework [Error]:
> couldn't get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i /var/root/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> Process 1866 launched: '/opt/aspera/bin/ascp' (x86_64)
>
> Session Stop  (Error: Session initiation failed, Server process failed to
> start: permissions?)
> Process 1866 exited with status = 1 (0x0001)
>
> I have another machine running OS X 10.9 and lldb where everything works
> flawlessly.
>
> The problem with out binary seems to be that OS X is prohibiting our
> binary from starting another process (even as root).  Not sure if this is
> the right list for that question though.  Assume it's something to do with
> 10.11's security model.
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

[Jason Molenda via lldb-dev]

Hi Tony.  There are new security mechanisms in Mac OS X 10.11 El Capitan, 
called System Integrity Protection, but I don't recognize this failure mode.  
Try a stripped down example, like

$ echo 'int main () { }' > /tmp/a.c
$ xcrun clang /tmp/a.c -o /tmp/a.out
$ xcrun lldb /tmp/a.out
(lldb) br s -n main
(lldb) r

That should work.  That's a baseline, then we can start working on why your 
example isn't working.



> On Oct 2, 2015, at 2:35 PM, Tony Perrie via lldb-dev 
>  wrote:
> 
> I can only seem to debug our binary as the root user om 10.11.  I rebooted at 
> one point, and lldb did work briefly with a system user but then after the 
> machine ran for a bit, it proceeded to not work again.  Rebooted again, and 
> again, lldb failes with this error...
> 
> lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:24:17.091 lldb[1721:12884] Metadata.framework [Error]: couldn't 
> get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i ~/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> error: process exited with status -1 (unable to attach)
> 
> As root, I can reproduce the error:
> 
> root# lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:30:40.515 lldb[1864:14630] Metadata.framework [Error]: couldn't 
> get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i /var/root/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> Process 1866 launched: '/opt/aspera/bin/ascp' (x86_64)
> 
> Session Stop  (Error: Session initiation failed, Server process failed to 
> start: permissions?)
> Process 1866 exited with status = 1 (0x0001) 
> 
> I have another machine running OS X 10.9 and lldb where everything works 
> flawlessly.
> 
> The problem with out binary seems to be that OS X is prohibiting our binary 
> from starting another process (even as root).  Not sure if this is the right 
> list for that question though.  Assume it's something to do with 10.11's 
> security model.
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] TestAttachDenied - timing out

[Todd Fiala via lldb-dev]

Thanks, Oleksiy!


On Tue, Sep 29, 2015 at 5:08 PM, Oleksiy Vyalov  wrote:

> Test used to be flaky from time to time but in
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6802
> it failed consistently for all configurations - that's pretty suspicious.
> Test inferior writes some output to stdout and stderr - I don't have a lot
> of context about http://reviews.llvm.org/D13124 but as I can see all
> standard streams are set to subprocess.PIPE, as a guess
> maybe inferior tries to write sth in stdout/stderr but nobody is reading
> this data on python side.
>
>
> On Tue, Sep 29, 2015 at 4:17 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I killed build 6803 on the Linux buildbot since the tests would have
>> taken 25+ minutes to run through the timeout on the theory that getting the
>> results net faster would be better.  6804+ should have the test disabled
>> that was timing out.
>>
>> On Tue, Sep 29, 2015 at 4:09 PM, Todd Fiala  wrote:
>>
>>> I disabled it on Linux with this:
>>> svn commit
>>> Sending
>>>  functionalities/process_attach/attach_denied/TestAttachDenied.py
>>> Transmitting file data .
>>> Committed revision 248846.
>>>
>>>
>>>
>>> On Tue, Sep 29, 2015 at 4:02 PM, Todd Fiala 
>>> wrote:
>>>
 That said, I'm going to disable the test and look into why it is timing
 out so our poor Google test runner doesn't take forever to go through the
 tests.

 I'll file a ticket and look into it.

 On Tue, Sep 29, 2015 at 3:54 PM, Todd Fiala 
 wrote:

> Hi all,
>
> I've been running the test suite for quite some time on the Linux
> side.  I pretty consistently see this test case file:
>
> TestAttachDenied.py
>
> time out on my Linux setup (prior to any of my test runner changes).
> I'm noticing it is now showing up on the Google Linux buildbot (here
> - build 6802
> 
> ).
>
> I just wanted to throw out there that this isn't a new phenomenon on
> my end (Ubuntu 14.04 x86_64 built with clang 3.6 and tested with inferiors
> built with clang 3.6).
>
> --
> -Todd
>



 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Oleksiy Vyalov | Software Engineer | ovya...@google.com
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

[Jason Molenda via lldb-dev]

The fact that it doesn't work as root makes it less likely it's an unsigned 
debugserver / missigned debugserver issue.  You can run an unsigned / 
mis-signed lldb as root and it will still work on os x 10.11, as well as a 
signed one run by a user account.

Is the binary you're running under the debugger signed?  I think it needs the 
get-task-allow entitlement if the debugger is going to attach/run it.


> On Oct 2, 2015, at 5:58 PM, Todd Fiala via lldb-dev  
> wrote:
> 
> Hi Tony,
> 
> This is the right list.
> 
> Are you using an LLDB that you built locally?  If so, can you move aside the 
> debugserver that you find somewhere under in your LLDB.framework bundle 
> directory, and make a symlink to the debugserver that comes out of your 
> /Applications/Xcode.app bundle?  Your official Xcode.app one should be in a 
> location like:
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
> 
> The other thing it could be is that I think your lldb_codesign cert may need 
> to be recreated on a new OS.  I seem to recall the instructions there 
> indicate the code signing cert does not survive OS updates but I might be 
> mistaken.
> 
> I suspect the symlink will resolve your issue, though.  With tighter 
> security, it is likely that a home-built debugserver is no longer going to 
> work without being Apple signed.  We may need to adjust the Xcode build to 
> create a symlink to the official one if that's the case.
> 
> -Todd
> 
> On Fri, Oct 2, 2015 at 2:35 PM, Tony Perrie via lldb-dev 
>  wrote:
> I can only seem to debug our binary as the root user om 10.11.  I rebooted at 
> one point, and lldb did work briefly with a system user but then after the 
> machine ran for a bit, it proceeded to not work again.  Rebooted again, and 
> again, lldb failes with this error...
> 
> lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:24:17.091 lldb[1721:12884] Metadata.framework [Error]: couldn't 
> get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i ~/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> error: process exited with status -1 (unable to attach)
> 
> As root, I can reproduce the error:
> 
> root# lldb /opt/aspera/bin/ascp
> (lldb) target create "/opt/aspera/bin/ascp"
> 2015-10-02 14:30:40.515 lldb[1864:14630] Metadata.framework [Error]: couldn't 
> get the client port
> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
> (lldb) r -i /var/root/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
> Process 1866 launched: '/opt/aspera/bin/ascp' (x86_64)
> 
> Session Stop  (Error: Session initiation failed, Server process failed to 
> start: permissions?)
> Process 1866 exited with status = 1 (0x0001) 
> 
> I have another machine running OS X 10.9 and lldb where everything works 
> flawlessly.
> 
> The problem with out binary seems to be that OS X is prohibiting our binary 
> from starting another process (even as root).  Not sure if this is the right 
> list for that question though.  Assume it's something to do with 10.11's 
> security model.
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

[Tony Perrie via lldb-dev]

The lldb I'm using is from XCode 7.0.1.

I can debug my binary if I run lldb as root.

I eventually figured out my actual bug from log messages without lldb.  Turns 
out, Mac OS X 10.11 El Capitan doesn't allow the root user to deploy binaries 
to /usr/bin which our installer does so that our binary is in the default ssh 
environment path.  I setup a custom ~/.ssh/environment and configured 
PermitUserEnvironment to yes in /etc/sshd_config and that let my binary run 
normally.

But, still, I can't seem to run lldb as a normal system user with our binary.

Tony

> On Oct 2, 2015, at 6:05 PM, Jason Molenda  wrote:
> 
> The fact that it doesn't work as root makes it less likely it's an unsigned 
> debugserver / missigned debugserver issue.  You can run an unsigned / 
> mis-signed lldb as root and it will still work on os x 10.11, as well as a 
> signed one run by a user account.
> 
> Is the binary you're running under the debugger signed?  I think it needs the 
> get-task-allow entitlement if the debugger is going to attach/run it.
> 
> 
>> On Oct 2, 2015, at 5:58 PM, Todd Fiala via lldb-dev 
>>  wrote:
>> 
>> Hi Tony,
>> 
>> This is the right list.
>> 
>> Are you using an LLDB that you built locally?  If so, can you move aside the 
>> debugserver that you find somewhere under in your LLDB.framework bundle 
>> directory, and make a symlink to the debugserver that comes out of your 
>> /Applications/Xcode.app bundle?  Your official Xcode.app one should be in a 
>> location like:
>> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
>> 
>> The other thing it could be is that I think your lldb_codesign cert may need 
>> to be recreated on a new OS.  I seem to recall the instructions there 
>> indicate the code signing cert does not survive OS updates but I might be 
>> mistaken.
>> 
>> I suspect the symlink will resolve your issue, though.  With tighter 
>> security, it is likely that a home-built debugserver is no longer going to 
>> work without being Apple signed.  We may need to adjust the Xcode build to 
>> create a symlink to the official one if that's the case.
>> 
>> -Todd
>> 
>> On Fri, Oct 2, 2015 at 2:35 PM, Tony Perrie via lldb-dev 
>>  wrote:
>> I can only seem to debug our binary as the root user om 10.11.  I rebooted 
>> at one point, and lldb did work briefly with a system user but then after 
>> the machine ran for a bit, it proceeded to not work again.  Rebooted again, 
>> and again, lldb failes with this error...
>> 
>> lldb /opt/aspera/bin/ascp
>> (lldb) target create "/opt/aspera/bin/ascp"
>> 2015-10-02 14:24:17.091 lldb[1721:12884] Metadata.framework [Error]: 
>> couldn't get the client port
>> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
>> (lldb) r -i ~/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
>> error: process exited with status -1 (unable to attach)
>> 
>> As root, I can reproduce the error:
>> 
>> root# lldb /opt/aspera/bin/ascp
>> (lldb) target create "/opt/aspera/bin/ascp"
>> 2015-10-02 14:30:40.515 lldb[1864:14630] Metadata.framework [Error]: 
>> couldn't get the client port
>> Current executable set to '/opt/aspera/bin/ascp' (x86_64).
>> (lldb) r -i /var/root/.ssh/id_rsa /tmp/mp_source/* localhost:/tmp/mp_dest/
>> Process 1866 launched: '/opt/aspera/bin/ascp' (x86_64)
>> 
>> Session Stop  (Error: Session initiation failed, Server process failed to 
>> start: permissions?)
>> Process 1866 exited with status = 1 (0x0001) 
>> 
>> I have another machine running OS X 10.9 and lldb where everything works 
>> flawlessly.
>> 
>> The problem with out binary seems to be that OS X is prohibiting our binary 
>> from starting another process (even as root).  Not sure if this is the right 
>> list for that question though.  Assume it's something to do with 10.11's 
>> security model.
>> 
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
>> 
>> 
>> -- 
>> -Todd
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev