[lldb-dev] Code coverage of llvm, clang, lldb & polly

Malea, Daniel daniel.malea at intel.com
Fri May 31 09:04:40 PDT 2013


Yeah, it's somewhat surprising that 'ps' is not being found..it doesn't
seem to be on the PATH. In any case, no rush, I will continue looking at
some of the other test failures that are happening only on Debian builds
in the mean time..

Thanks,
Dan

On 2013-05-31 11:58 AM, "Sylvestre Ledru" <sylvestre at debian.org> wrote:

>Oh. I would have say that ps was installed by default in a chroot :)
>Maybe it was(is?) the case for Ubuntu.
>Anyway, I just applied your patch and relaunched a build (but note that
>the code coverage takes
>between 4h to 5h30)
>
>Thanks :)
>Sylvestre
>
>Le 31/05/2013 17:51, Malea, Daniel a écrit :
>> Thanks for the update. It's clear that ps is not being installed in the
>> chroot environments. I checked the debian/control file and there's no
>> build depends on it; try the attached patch that adds a Build-Depends on
>> procps package.
>>
>> Thanks,
>> Dan
>>
>>
>> On 2013-05-31 10:46 AM, "Sylvestre Ledru" <sylvestre at debian.org> wrote:
>>
>>> On 31/05/2013 00:31, Malea, Daniel wrote:
>>>> Hi Sylvestre, I committed a potential fix for the 'ps' issue in
>>>>182965.
>>> It fails with:
>>> Traceback (most recent call last):
>>>  File
>>> 
>>>"/tmp/buildd/llvm-toolchain-snapshot-3.4~svn182989/lldb/test/dotest.py",
>>> line 1210, in <module>
>>>    print >> f, "Command invoked: %s\n" % getMyCommandLine()
>>>  File
>>> 
>>>"/tmp/buildd/llvm-toolchain-snapshot-3.4~svn182989/lldb/test/dotest.py",
>>> line 1074, in getMyCommandLine
>>>    ps = subprocess.Popen([which('ps'), '-o', "command=CMD",
>>> str(os.getpid())], stdout=subprocess.PIPE).communicate()[0]
>>>  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
>>>    errread, errwrite)
>>>  File "/usr/lib/python2.7/subprocess.py", line 1308, in _execute_child
>>>    raise child_exception
>>> AttributeError: 'NoneType' object has no attribute 'rfind'
>>>
>>>
>>>> Out of curiosity, is the code-coverage run happening on a different
>>>> machine than the normal testing runs? For example, I'm seeing:
>>>>
>>>>
>>>> 
>>>>http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/arch
>>>>it
>>>> ec
>>>> ture=amd64,distribution=quantal/166/consoleText
>>>>
>>>> Doesn't have any problems finding 'ps' when running the tests. It
>>>>seems
>>>> odd that 'ps' is not being found..could it maybe be in a (different)
>>>> chroot environment where ps is not available for some reason?
>>> Besides the code coverage build flags, there is no difference.
>>> However, all the system is different. That means that the Python under
>>> quantal is probably different from the one in Debian Unstable.
>>>
>>> Cheers,
>>> Sylvestre
>>>
>





More information about the lldb-dev mailing list