rizsotto.mailinglist added inline comments. ================ Comment at: tools/scan-build-py/libear/ear.c:142 @@ +141,3 @@ +#endif + if (!initialized) + initialized = bear_capture_env_t(&initial_env); ---------------- dcoughlin wrote: > rizsotto.mailinglist wrote: > > rizsotto.mailinglist wrote: > > > to run the full test set > > > > > > > PATH=$(pwd)/bin:$PATH python -m unittest discover > > > > > > to run that specific test > > > > > > > PATH=$(pwd)/bin:$PATH python -m unittest -v > > > > tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env > > > > > > to more about run tests > > > > > > https://docs.python.org/2/library/unittest.html > > my understanding on the `_NSGetEnviron` is, that it shall be used when the > > library is during the load process. later when the build process calls > > `execv` the load process is over, and `environ` variable is available. an > > earlier version of this code had a `get_environ` method, which were either > > return the `environ` variable or called the `_NSGetEnviron`. then i made > > this change and the tests were still passing, so i don't see where your > > issue is coming from. please tell me what kind of test you run against it > > to find it as problem. would like to add it to the test suite. > Aaah, I had an ancient libscanbuild in my global site-packages, which seemed > to cause `unittest discover` to not work. > > When running the above on your latest patch on a machine without SIP I get. > > ``` > test_successful_build_on_empty_env > (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) ... ERROR > > ====================================================================== > ERROR: test_successful_build_on_empty_env > (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "tests/functional/cases/test_create_cdb.py", line 58, in > test_successful_build_on_empty_env > 'env', '-'] + make) > File "tests/functional/cases/__init__.py", line 38, in silent_check_call > return subprocess.check_call(cmd, *args, **kwargs) > File > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", > line 540, in check_call > raise CalledProcessError(retcode, cmd) > CalledProcessError: Command '['intercept-build', '--cdb', > '/var/folders/mq/46lsd1kx65v5702dzrkgzdlr0000gn/T/scan-build-test-cKXza1/cdb.json', > 'env', '-', 'make', 'SRCDIR=tests/functional/src', > 'OBJDIR=/var/folders/mq/46lsd1kx65v5702dzrkgzdlr0000gn/T/scan-build-test-cKXza1', > '-f', 'tests/functional/src/build/Makefile', 'CC=clang', 'build_regular']' > returned non-zero exit status 2 > > ---------------------------------------------------------------------- > Ran 1 test in 0.554s > > FAILED (errors=1) > ``` > This goes away if you use my suggested *_NSGetEnviron() fix above. > After applying that fix, all but 6 test past on OS X without SIP. The > remaining 6 failures are due to your use of mknod() in tests, which requires > superuser privileges on OS X: > > > ``` > ====================================================================== > ERROR: test_interposition_cxx_works > (tests.functional.cases.test_from_cmd.RunAnalyzerTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/Volumes/Data/Clangs/OpenSourceGit/clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py", > line 102, in test_interposition_cxx_works > self.compile_empty_source_file(tmpdir, True)) > File > "/Volumes/Data/Clangs/OpenSourceGit/clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py", > line 87, in compile_empty_source_file > os.mknod(src_file) > OSError: [Errno 1] Operation not permitted > ``` > > Is there a more portable way to create an empty file? Perhaps open a file for > writing and then closing it? > > > With SIP I see different failures: > > ``` > workzilla:scan-build-py dcoughlin$ PATH=$(pwd)/bin:$PATH python -m unittest > -v > tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env > test_successful_build_on_empty_env > (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) ... FAIL > > ====================================================================== > FAIL: test_successful_build_on_empty_env > (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "tests/functional/cases/test_create_cdb.py", line 60, in > test_successful_build_on_empty_env > self.assertEqual(5, self.count_entries(result)) > AssertionError: 5 != 0 > > ---------------------------------------------------------------------- > Ran 1 test in 1.069s > > FAILED (failures=1) > ``` > > Running the entire test suite with SIP yields: > > ``` > FFFFF...EEFFE..................FEEF.EE............................................... > ... > Ran 85 tests in 15.688s > > FAILED (failures=9, errors=7) > ``` > I tried changing intercept.py to always use compiler wrappers on Darwin, but > some tests were still failing > (tests.functional.cases.test_exec_anatomy.ExecAnatomyTest, > tests.functional.cases.test_create_cdb.CompilationDatabaseTest). Do you > expect these tests to pass with compiler wrappers? Do they pass for you with > compiler wrappers? Or is this some Darwin-specific issue? thanks Devin, these are interesting findings. however i managed to access to an OS X machine today, have no chance to turn on-and-off the SIP (it was most probably off). and it passed all the tests without any change.
> $ uname -v > Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; > root:xnu-2422.115.14~1/RELEASE_X86_64 anyway, i did replaced the `mknod` call. and also implemented a way to call `_NSGetEnviron` rather than access to environment variable. (tests are still passing on this machine.) and the `ExecAnatomyTest` is about to capture the different `exec` calls by the `libear` library. would not make sense with compiler wrappers. http://reviews.llvm.org/D9600 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits