<div dir="ltr"><div>> If your kernel version is 3.10.0-123 then you are *way* backlevel. That<br>> is the original 7.0 kernel and the rest of your system is likely to also<br>> be at the same 2.5 year old level. You should `yum update` and retest on<br>> 7.3.<br>> <br>> Trevor<br>> </div><div><br></div><div>I upgraded the kernel version to 4.11.1-1.el7.elrepo.x86_64 #1 SMP Sun May 14 11:54:29 EDT 2017 and performed the tests. However the result remains unchanged - the test hangs. I can provide the complete log file if required.</div><div><br></div><div>There is something interesting going on around line 16698 ("[pid 22714] _exit(0)") in the log file excerpt.</div><div><br></div><div>[pid 22703] futex(0x7f7dd0000f20, FUTEX_WAKE_PRIVATE, 1) = 0<br>[pid 22703] sendmsg(8, {msg_name(0)=NULL, msg_iov(3)=[{"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n", 24}, {"\0\0\22\4\0\0\0\0\0\0\2\0\0\0\0\0\3\0\0\0\0\0\4\0\0\377\377", 27}, {"\0\0\4\10\0\0\0\0\0\0\17\0\1", 13}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 64<br>[pid 22703] clock_gettime(CLOCK_MONOTONIC, {1155, 662752484}) = 0<br>[pid 22703] poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN|POLLOUT}], 3, 999) = 1 ([{fd=8, revents=POLLOUT}])<br>[pid 22703] clock_gettime(CLOCK_MONOTONIC, {1155, 662807734}) = 0<br>[pid 22703] poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 3, 999 <unfinished ...><br>[pid 22714] clock_gettime(CLOCK_MONOTONIC, {1155, 662865341}) = 0<br>[pid 22714] sendmsg(8, {msg_name(0)=NULL, msg_iov(16)=[{"\0\1\22\1\4\0\0\0\1@\7", 11}, {":scheme", 7}, {"\4", 1}, {"http", 4}, {"@\7", 2}, {":method", 7}, {"\4", 1}, {"POST", 4}, {"@\5", 2}, {":path", 5}, {"\"", 1}, {"/command_server.CommandServer/Pi"..., 34}, {"@\n", 2}, {":authority", 10}, {"\v[::1]:42219@\r", 14}, {"grpc-encoding", 13}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 118<br>[pid 22714] sendmsg(8, {msg_name(0)=NULL, msg_iov(16)=[{"\10", 1}, {"identity", 8}, {"@\24", 2}, {"grpc-accept-encoding", 20}, {"\25", 1}, {"identity,deflate,gzip", 21}, {"@\2", 2}, {"te", 2}, {"\10", 1}, {"trailers", 8}, {"@\f", 2}, {"content-type", 12}, {"\20", 1}, {"application/grpc", 16}, {"@\n", 2}, {"user-agent", 10}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 109<br>[pid 22714] sendmsg(8, {msg_name(0)=NULL, msg_iov(8)=[{"%", 1}, {"grpc-c++/0.13.0 grpc-c/0.13.0 (l"..., 37}, {"@\f", 2}, {"grpc-timeout", 12}, {"\00310S\0\0\4\10\0\0\0\0\1\0\0", 15}, {"\377\377\0\0%\0\1\0\0\0\1\0\0\0\0", 15}, {" ", 1}, {"\n\03646fec02652d766b966d8d8da6f32ae", 32}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 115<br>[pid 22714] madvise(0x7f7dd6606000, 8368128, MADV_DONTNEED) = 0<br>[pid 22714] _exit(0) = ?<br>[pid 22703] <... poll resumed> ) = 1 ([{fd=8, revents=POLLIN}])<br>[pid 22714] +++ exited with 0 +++<br>recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\f\4\0\0\0\0\0\0\3\177\377\377\377\0\4\0\20\0\0\0\0\4\10\0\0\0\0\0\0\17"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 183<br>sendmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0\0\0\4\1\0\0\0\0", 9}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 9<br>recvmsg(8, 0x7ffc26b44450, 0) = -1 EAGAIN (Resource temporarily unavailable)<br>open("/root/.cache/bazel/_bazel_root/038a9c24c67a3f14ac28680c554d9af8/server/server.pid.txt", O_RDONLY) = 9<br>read(9, "11702", 32) = 5<br>read(9, "", 27) = 0<br>close(9) = 0<br>readlink("/root/.cache/bazel/_bazel_root/038a9c24c67a3f14ac28680c554d9af8/install", "/root/.cache/bazel/_bazel_root/i"..., 4096) = 71<br>open("/root/.cache/bazel/_bazel_root/038a9c24c67a3f14ac28680c554d9af8/server/cmdline", O_RDONLY) = 9<br>read(9, "bazel(root)\0-XX:+HeapDumpOnOutOf"..., 4096) = 948<br>read(9, "", 4096) = 0<br>close(9) = 0<br>unlink("/root/.cache/bazel/_bazel_root/038a9c24c67a3f14ac28680c554d9af8/javalog.properties") = 0<br>open("/root/.cache/bazel/_bazel_root/038a9c24c67a3f14ac28680c554d9af8/javalog.properties", O_WRONLY|O_CREAT|O_TRUNC, 0755) = 9<br>write(9, "handlers=java.util.logging.FileH"..., 380) = 380<br>close(9) = 0<br>readlink("/proc/11702/cwd", "/root/bazel", 4096) = 11<br>clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 32832517}) = 0<br>rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0<br>rt_sigaction(SIGINT, {0x420c70, [INT], SA_RESTORER|SA_RESTART, 0x7f7dd8d12250}, {SIG_DFL, [], 0}, 8) = 0<br>rt_sigaction(SIGTERM, {0x420c70, [TERM], SA_RESTORER|SA_RESTART, 0x7f7dd8d12250}, {SIG_DFL, [], 0}, 8) = 0<br>rt_sigaction(SIGPIPE, {0x420c70, [PIPE], SA_RESTORER|SA_RESTART, 0x7f7dd8d12250}, {SIG_DFL, [], 0}, 8) = 0<br></div><div><br></div><div>Thanks,</div><div>Atul.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 4:59 PM, Atul Sowani <span dir="ltr"><<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div>Hi,</div><div><br></div><div>I have observed that certain Bazel test cases from the test suite are timing out on CentOS 7 (kernel version 3.10.0-123.el7.x86_64). For example, I tried bazel_coverage_test (using command bazel test //src/test/shell/bazel:bazel_<wbr>coverage_test) and observed that it just hangs. I tried tracing it using strace (log attached).</div><div><br></div><div>This seems to be CentOS specific behavior as I did not observe this on Ubuntu 16.04.</div><div><br></div><div>Has anybody observed this? Is this a regression as far as CentOS is concerned?</div><div><br></div><div>Thanks,</div><div>Atul.<br></div></div>
</blockquote></div><br></div></div>