Hi,
It looks like the following bots assigned to you started failing recently:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-noe...
The failing tests are all filesystem tests:
FAIL: libc++::assign.pass.cpp FAIL: libc++::path.pass.cpp FAIL: libc++::replace_filename.pass.cpp FAIL: libc++::refresh.pass.cpp FAIL: libc++::file_size.pass.cpp FAIL: libc++::file_type_obs.pass.cpp FAIL: libc++::hard_link_count.pass.cpp FAIL: libc++::last_write_time.pass.cpp FAIL: libc++::ctor.pass.cpp FAIL: libc++::ctor.pass.cpp FAIL: libc++::increment.pass.cpp FAIL: libc++::exists.pass.cpp FAIL: libc++::is_block_file.pass.cpp FAIL: libc++::is_character_file.pass.cpp FAIL: libc++::is_directory.pass.cpp FAIL: libc++::is_empty.pass.cpp FAIL: libc++::is_fifo.pass.cpp FAIL: libc++::is_other.pass.cpp FAIL: libc++::is_regular_file.pass.cpp FAIL: libc++::is_socket.pass.cpp
Having seen some of these issues before, I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
Can you work with us to resolve this issue?
Thanks, Louis
It looks like the following bots assigned to you started failing recently:
I agree the bots should be fixed, but...
I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
It seems like these tests could have a line like: ``` REQUIRES: -user=root ``` and libcxx's lit target could export a `user=root` feature when tests were being run as root. WDYT?
WDYT?
On Apr 2, 2020, at 14:05, Duncan Exon Smith dexonsmith@apple.com wrote:
It looks like the following bots assigned to you started failing recently:
I agree the bots should be fixed, but...
I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
It seems like these tests could have a line like:
REQUIRES: -user=rootand libcxx's lit target could export a `user=root` feature when tests were being run as root. WDYT?
WDYT?
I think you mean `// UNSUPPORTED: -user=root`? Yes, I think it would make sense. Either that or actually spend the time to make them work as root.
FWIW, I think the root cause of the issue is that "traverse" permissions in directories are not honoured when run as root:
root $ d=$(mktemp -d) root $ touch $d/foo root $ chmod 000 $d root $ stat $d/foo 16777221 234259215 -rw-r--r-- 1 root wheel 0 0 <...>
When I would expect:
ldionne $ d=$(mktemp -d) ldionne $ touch $d/foo ldionne $ chmod 000 $d ldionne $ stat $d/foo stat: <...>/tmp.JoY6Ixmo/foo: stat: Permission denied
Does that make sense? I didn't know 'root' had a free pass like that.
Louis
On 2020-Apr-02, at 11:23, Louis Dionne ldionne@apple.com wrote:
On Apr 2, 2020, at 14:05, Duncan Exon Smith <dexonsmith@apple.com mailto:dexonsmith@apple.com> wrote:
It looks like the following bots assigned to you started failing recently:
I agree the bots should be fixed, but...
I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
It seems like these tests could have a line like:
REQUIRES: -user=rootand libcxx's lit target could export a `user=root` feature when tests were being run as root. WDYT?
WDYT?
I think you mean `// UNSUPPORTED: -user=root`? Yes, I think it would make sense. Either that or actually spend the time to make them work as root.
I meant `REQUIRES: !user=root`, I used the wrong negation.
FWIW, I think the root cause of the issue is that "traverse" permissions in directories are not honoured when run as root:
root $ d=$(mktemp -d) root $ touch $d/foo root $ chmod 000 $d root $ stat $d/foo 16777221 234259215 -rw-r--r-- 1 root wheel 0 0 <...>When I would expect:
ldionne $ d=$(mktemp -d) ldionne $ touch $d/foo ldionne $ chmod 000 $d ldionne $ stat $d/foo stat: <...>/tmp.JoY6Ixmo/foo: stat: Permission deniedDoes that make sense? I didn't know 'root' had a free pass like that.
Louis
On 2020-Apr-02, at 13:10, Duncan Exon Smith via libcxx-dev libcxx-dev@lists.llvm.org wrote:
On 2020-Apr-02, at 11:23, Louis Dionne <ldionne@apple.com mailto:ldionne@apple.com> wrote:
On Apr 2, 2020, at 14:05, Duncan Exon Smith <dexonsmith@apple.com mailto:dexonsmith@apple.com> wrote:
It looks like the following bots assigned to you started failing recently:
I agree the bots should be fixed, but...
I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
It seems like these tests could have a line like:
REQUIRES: -user=rootand libcxx's lit target could export a `user=root` feature when tests were being run as root. WDYT?
WDYT?
I think you mean `// UNSUPPORTED: -user=root`? Yes, I think it would make sense. Either that or actually spend the time to make them work as root.
I meant `REQUIRES: !user=root`, I used the wrong negation.
Although UNSUPPORTED is maybe more clear.
FWIW, I think the root cause of the issue is that "traverse" permissions in directories are not honoured when run as root:
root $ d=$(mktemp -d) root $ touch $d/foo root $ chmod 000 $d root $ stat $d/foo 16777221 234259215 -rw-r--r-- 1 root wheel 0 0 <...>When I would expect:
ldionne $ d=$(mktemp -d) ldionne $ touch $d/foo ldionne $ chmod 000 $d ldionne $ stat $d/foo stat: <...>/tmp.JoY6Ixmo/foo: stat: Permission deniedDoes that make sense? I didn't know 'root' had a free pass like that.
Louis
libcxx-dev mailing list libcxx-dev@lists.llvm.org mailto:libcxx-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
Hi Louis and Duncan,
Sorry the issue is indeed on our si8de, the bot is not run as run root, but some manual investigation last week accidentally created these files with root ownership, sorry for that.
Thanks Yvan
On Mon, 6 Apr 2020 at 10:09, Duncan Exon Smith dexonsmith@apple.com wrote:
On 2020-Apr-02, at 13:10, Duncan Exon Smith via libcxx-dev <
libcxx-dev@lists.llvm.org> wrote:
On 2020-Apr-02, at 11:23, Louis Dionne <ldionne@apple.com <mailto:
ldionne@apple.com>> wrote:
On Apr 2, 2020, at 14:05, Duncan Exon Smith <dexonsmith@apple.com
mailto:dexonsmith@apple.com> wrote:
It looks like the following bots assigned to you started failing
recently:
I agree the bots should be fixed, but...
I strongly suspect this is due to the fact that your builder is
running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
It seems like these tests could have a line like:
REQUIRES: -user=rootand libcxx's lit target could export a `user=root` feature when tests
were being run as root. WDYT?
WDYT?
I think you mean `// UNSUPPORTED: -user=root`? Yes, I think it would
make sense. Either that or actually spend the time to make them work as root.
I meant `REQUIRES: !user=root`, I used the wrong negation.
Although UNSUPPORTED is maybe more clear.
FWIW, I think the root cause of the issue is that "traverse"
permissions in directories are not honoured when run as root:
root $ d=$(mktemp -d) root $ touch $d/foo root $ chmod 000 $d root $ stat $d/foo 16777221 234259215 -rw-r--r-- 1 root wheel 0 0 <...>When I would expect:
ldionne $ d=$(mktemp -d) ldionne $ touch $d/foo ldionne $ chmod 000 $d ldionne $ stat $d/foo stat: <...>/tmp.JoY6Ixmo/foo: stat: Permission deniedDoes that make sense? I didn't know 'root' had a free pass like that.
Louis
libcxx-dev mailing list libcxx-dev@lists.llvm.org mailto:libcxx-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <
https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev%3E _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Duncan Exon Smith -
Louis Dionne -
Yvan Roux