[Lldb-commits] Buildbot numbers for the week of 07/16/2017 - 07/22/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the week of 07/16/2017 - 07/22/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername | was_red
+-
 clang-x86_64-linux-selfhost-modules| 69:57:24
 sanitizer-windows  | 42:25:18
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 33:46:22
 clang-cmake-aarch64-global-isel| 25:07:46
 libcxx-libcxxabi-libunwind-aarch64-linux   | 21:55:48
 clang-ppc64be-linux-multistage | 13:36:25
 lldb-windows7-android  | 13:23:53
 clang-x64-ninja-win7   | 12:59:55
 sanitizer-x86_64-linux-bootstrap   | 12:45:32
 clang-with-thin-lto-windows| 11:59:46
 clang-x86-windows-msvc2015 | 11:49:50
 lldb-x86_64-ubuntu-14.04-cmake | 11:40:20
 lldb-x86_64-ubuntu-14.04-android   | 11:19:36
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 11:18:57
 clang-ppc64le-linux-multistage | 10:22:28
 llvm-clang-x86_64-expensive-checks-win | 10:20:01
 sanitizer-x86_64-linux-fast| 10:19:13
 lldb-amd64-ninja-netbsd8   | 10:11:49
 clang-ppc64be-linux-lnt| 10:05:48
 clang-with-lto-ubuntu  | 08:48:01
 clang-ppc64be-linux| 07:38:15
 clang-bpf-build| 07:37:20
 sanitizer-ppc64le-linux| 06:54:57
 clang-cmake-thumbv7-a15-full-sh| 06:00:38
 clang-with-thin-lto-ubuntu | 05:38:52
 ubuntu-gcc7.1-werror   | 05:35:27
 clang-lld-x86_64-2stage| 05:27:24
 clang-cmake-armv7-a15-selfhost-neon| 05:03:05
 libomp-ompt-gcc-x86_64-linux-debian| 04:55:31
 libomp-gcc-x86_64-linux-debian | 04:54:28
 perf-x86_64-penryn-O3  | 04:49:10
 lldb-x86-windows-msvc2015  | 04:36:42
 sanitizer-x86_64-linux-android | 04:29:08
 clang-atom-d525-fedora-rel | 04:18:27
 lldb-x86_64-ubuntu-14.04-buildserver   | 04:15:20
 clang-cmake-aarch64-lld| 03:51:46
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 03:50:56
 lld-x86_64-freebsd | 03:50:18
 lld-x86_64-darwin13| 03:50:01
 lldb-amd64-ninja-freebsd11 | 03:44:14
 clang-s390x-linux-multistage   | 03:24:51
 sanitizer-x86_64-linux | 03:16:12
 clang-x86_64-linux-selfhost-modules-2  | 03:12:30
 clang-ppc64le-linux-lnt| 02:46:30
 clang-ppc64le-linux| 02:41:41
 clang-x86_64-debian-fast   | 02:20:46
 libcxx-libcxxabi-libunwind-x86_64-linux-debian | 02:20:29
 clang-cmake-aarch64-quick  | 02:00:39
 clang-s390x-linux-lnt  | 01:52:29
 clang-s390x-linux  | 01:42:42
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:40:13
 lldb-x86_64-darwin-13.4| 01:38:52
 clang-native-arm-lnt   | 01:37:32
 sanitizer-x86_64-linux-autoconf| 01:25:17
 clang-cmake-armv7-a15-full | 01:25:01
 sanitizer-x86_64-linux-fuzzer  | 01:24:08
 clang-cmake-thumbv7-a15| 01:22:57
 clang-cmake-armv7-a15  | 01:21:58
 lld-x86_64-win7| 01:20:00
 clang-cmake-aarch64-42vma

[Lldb-commits] Buildbot numbers for the week of 07/23/2017 - 07/29/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the week of 07/23/2017 - 07/29/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername |  was_red
+--
 clang-x64-ninja-win7   | 124:58:50
 aosp-O3-polly-before-vectorizer-unprofitable   | 119:55:53
 clang-cuda-build   | 78:44:11
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 77:27:52
 clang-x86-windows-msvc2015 | 77:11:15
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 65:36:46
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 58:55:13
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast   | 44:46:26
 clang-atom-d525-fedora-rel | 40:12:22
 perf-x86_64-penryn-O3-polly| 35:11:44
 perf-x86_64-penryn-O3  | 25:42:32
 perf-x86_64-penryn-O3-polly-fast   | 24:44:01
 clang-with-lto-ubuntu  | 24:08:41
 perf-x86_64-penryn-O3-polly-parallel-fast  | 23:09:47
 perf-x86_64-penryn-O3-polly-unprofitable   | 23:04:12
 clang-with-thin-lto-ubuntu | 21:44:48
 llvm-hexagon-elf   | 20:03:08
 sanitizer-windows  | 13:41:45
 sanitizer-x86_64-linux-fast| 13:02:43
 clang-ppc64be-linux| 12:24:16
 sanitizer-x86_64-linux-bootstrap   | 10:22:10
 sanitizer-ppc64be-linux| 09:57:42
 clang-cmake-thumbv7-a15| 08:22:50
 clang-cmake-armv7-a15  | 08:12:13
 sanitizer-x86_64-linux-android | 07:06:57
 sanitizer-x86_64-linux | 06:57:07
 clang-ppc64le-linux-lnt| 06:52:33
 clang-ppc64le-linux| 06:34:04
 clang-ppc64be-linux-lnt| 06:32:56
 clang-s390x-linux-lnt  | 06:12:43
 sanitizer-ppc64le-linux| 06:12:16
 clang-ppc64be-linux-multistage | 05:48:46
 clang-s390x-linux-multistage   | 05:46:44
 clang-s390x-linux  | 05:34:41
 clang-x86_64-debian-fast   | 05:30:09
 clang-cmake-armv7-a15-selfhost | 04:50:24
 lld-x86_64-freebsd | 04:45:36
 clang-lld-x86_64-2stage| 04:42:19
 clang-x86_64-linux-selfhost-modules-2  | 04:29:19
 clang-cmake-armv7-a15-selfhost-neon| 04:29:01
 clang-cmake-aarch64-quick  | 03:59:32
 clang-cmake-aarch64-lld| 03:57:35
 sanitizer-x86_64-linux-autoconf| 03:56:08
 clang-x86_64-linux-abi-test| 03:55:38
 clang-cmake-armv7-a15-full | 03:43:54
 clang-cmake-thumbv7-a15-full-sh| 03:42:41
 clang-bpf-build| 03:40:52
 lld-x86_64-darwin13| 03:36:13
 libcxx-libcxxabi-libunwind-aarch64-linux   | 03:34:39
 ubuntu-gcc7.1-werror   | 03:32:24
 clang-cmake-aarch64-42vma  | 03:21:06
 polly-amd64-linux  | 03:01:14
 lldb-x86_64-ubuntu-14.04-cmake | 02:50:05
 clang-with-thin-lto-windows| 02:49:50
 clang-cmake-aarch64-global-isel| 02:29:21
 llvm-clang-x86_64-expensive-checks-win | 02:24:59
 lldb-x86_64-ubuntu-14.04-android   | 02:24:18
 lldb-windows7-android  | 02:20:33
 libcxx-libcxxabi-x86_64-linux-debian   | 02:06:29
 lldb-x86_64-darwin-13.4  

[Lldb-commits] Buildbot numbers for the week of 07/30/2017 - 08/05/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the week of 07/30/2017 - 08/05/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername |  was_red
+--
 clang-x86_64-linux-selfhost-modules-2  | 119:41:05
 clang-x86_64-linux-selfhost-modules| 119:19:49
 clang-ppc64le-linux-multistage | 57:04:10
 aosp-O3-polly-before-vectorizer-unprofitable   | 47:48:00
 sanitizer-x86_64-linux-android | 39:04:10
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 29:22:26
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 29:13:00
 perf-x86_64-penryn-O3-polly| 26:24:24
 sanitizer-ppc64be-linux| 24:39:32
 sanitizer-ppc64le-linux| 24:22:07
 clang-cmake-x86_64-avx2-linux-perf | 21:56:09
 clang-ppc64le-linux-lnt| 19:18:21
 clang-ppc64le-linux| 19:17:15
 clang-ppc64be-linux| 18:59:05
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 17:52:15
 clang-ppc64be-linux-lnt| 17:21:33
 sanitizer-x86_64-linux-bootstrap   | 17:16:22
 sanitizer-windows  | 17:05:04
 clang-ppc64be-linux-multistage | 16:34:47
 sanitizer-x86_64-linux-fast| 15:32:33
 perf-x86_64-penryn-O3  | 14:14:15
 lldb-x86_64-ubuntu-14.04-cmake | 12:18:27
 clang-x86-windows-msvc2015 | 12:10:09
 clang-lld-x86_64-2stage| 11:42:52
 lldb-x86_64-darwin-13.4| 10:54:58
 lldb-x86_64-ubuntu-14.04-android   | 10:02:06
 lldb-windows7-android  | 09:04:01
 clang-with-thin-lto-ubuntu | 08:54:09
 clang-cmake-aarch64-quick  | 08:27:39
 clang-with-lto-ubuntu  | 08:26:53
 ubuntu-gcc7.1-werror   | 08:24:06
 clang-cmake-x86_64-avx2-linux  | 07:57:34
 clang-with-thin-lto-windows| 07:57:08
 clang-cmake-armv7-a15-selfhost | 07:56:05
 clang-x64-ninja-win7   | 07:54:38
 clang-x86_64-debian-fast   | 07:50:48
 clang-cuda-build   | 07:26:25
 clang-bpf-build| 07:26:02
 clang-cmake-aarch64-lld| 07:24:14
 clang-s390x-linux  | 07:19:16
 clang-cmake-armv7-a15-full | 07:11:56
 clang-atom-d525-fedora-rel | 07:10:30
 llvm-hexagon-elf   | 07:10:23
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 07:04:05
 clang-cmake-thumbv7-a15| 07:00:49
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan  | 06:59:04
 clang-s390x-linux-lnt  | 06:54:30
 clang-cmake-armv7-a15  | 06:53:40
 clang-cmake-aarch64-42vma  | 06:53:33
 clang-hexagon-elf  | 06:45:07
 clang-cmake-thumbv7-a15-full-sh| 06:45:01
 clang-cmake-aarch64-global-isel| 06:31:56
 clang-s390x-linux-multistage   | 05:12:28
 lld-x86_64-darwin13| 04:55:50
 polly-amd64-linux  | 04:47:46
 clang-cmake-armv7-a15-selfhost-neon| 04:03:14
 sanitizer-x86_64-linux-fuzzer  | 03:37:29
 polly-arm-linux| 02:42:21
 sanitizer-x86_64-linux | 02:39:19
 clang-native-arm-lnt 

[Lldb-commits] Buildbot numbers for the week of 08/06/2017 - 08/12/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the week of 08/06/2017 - 08/12/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername | was_red
+-
 sanitizer-x86_64-linux-fast| 75:05:34
 sanitizer-x86_64-linux-bootstrap   | 74:59:09
 clang-ppc64be-linux-lnt| 65:49:04
 clang-ppc64le-linux-multistage | 60:42:09
 perf-x86_64-penryn-O3-polly-before-vectorizer  | 50:15:20
 perf-x86_64-penryn-O3-polly-fast   | 46:18:42
 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 41:28:01
 clang-cmake-x86_64-avx2-linux-perf | 34:25:25
 perf-x86_64-penryn-O3-polly| 32:50:55
 llvm-mips-linux| 29:46:14
 perf-x86_64-penryn-O3  | 27:31:40
 clang-x86-windows-msvc2015 | 25:28:47
 clang-lld-x86_64-2stage| 25:00:42
 perf-x86_64-penryn-O3-polly-unprofitable   | 23:52:12
 perf-x86_64-penryn-O3-polly-parallel-fast  | 23:51:36
 clang-cmake-x86_64-avx2-linux  | 22:34:56
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only  | 21:56:36
 lldb-windows7-android  | 20:43:18
 lldb-x86_64-ubuntu-14.04-android   | 19:59:26
 lldb-x86_64-darwin-13.4| 19:56:11
 clang-atom-d525-fedora-rel | 19:52:28
 clang-ppc64be-linux-multistage | 19:33:41
 clang-ppc64le-linux-lnt| 19:29:25
 clang-with-lto-ubuntu  | 19:28:26
 clang-with-thin-lto-ubuntu | 19:18:01
 clang-ppc64le-linux| 19:10:44
 clang-s390x-linux-lnt  | 18:57:30
 clang-cmake-thumbv7-a15-full-sh| 18:52:32
 clang-x86_64-linux-selfhost-modules| 18:44:25
 clang-x86_64-linux-selfhost-modules-2  | 18:36:17
 clang-ppc64be-linux| 18:20:04
 clang-cmake-armv7-a15-selfhost | 17:42:02
 clang-x64-ninja-win7   | 17:31:27
 clang-s390x-linux-multistage   | 17:23:57
 lldb-x86_64-ubuntu-14.04-cmake | 17:08:49
 clang-s390x-linux  | 17:03:46
 clang-bpf-build| 16:58:20
 sanitizer-x86_64-linux-android | 16:32:14
 clang-cmake-armv7-a15-full | 15:48:43
 clang-cmake-armv7-a15-selfhost-neon| 13:51:40
 polly-arm-linux| 06:29:58
 clang-cmake-armv7-a15  | 05:45:31
 clang-cmake-thumbv7-a15| 05:44:12
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions  | 05:16:25
 libcxx-libcxxabi-libunwind-aarch64-linux   | 05:15:48
 libcxx-libcxxabi-libunwind-arm-linux   | 05:15:28
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions  | 05:14:33
 sanitizer-x86_64-linux | 04:48:24
 ubuntu-gcc7.1-werror   | 04:33:01
 clang-with-thin-lto-windows| 04:14:52
 clang-tools-sphinx-docs| 04:05:56
 clang-cmake-aarch64-lld| 03:53:19
 sanitizer-ppc64le-linux| 03:04:56
 sanitizer-ppc64be-linux| 02:49:07
 lld-x86_64-darwin13| 02:00:17
 clang-cmake-aarch64-quick  | 01:59:55
 sanitizer-x86_64-linux-fuzzer  | 01:55:22
 lldb-x86_64-ubuntu-14.04-buildserver   | 01:51:02
 lldb-x86-windows-msvc2015  | 01:23:04
 sanitizer-x86_64-linux-autoco

[Lldb-commits] Buildbot numbers for the week of 08/13/2017 - 08/19/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the week of 08/13/2017 - 08/19/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

buildername | was_red
+-
 clang-ppc64le-linux-lnt| 52:15:02
 clang-with-thin-lto-ubuntu | 45:50:37
 clang-with-lto-ubuntu  | 45:47:28
 clang-cuda-build   | 39:35:06
 sanitizer-windows  | 30:09:22
 clang-x86_64-debian-fast   | 27:29:32
 clang-cmake-x86_64-avx2-linux-perf | 25:29:12
 clang-lld-x86_64-2stage| 24:47:55
 clang-cmake-x86_64-avx2-linux  | 24:37:29
 clang-bpf-build| 20:51:26
 perf-x86_64-penryn-O3  | 20:47:21
 perf-x86_64-penryn-O3-polly| 20:41:57
 clang-x64-ninja-win7   | 19:51:04
 perf-x86_64-penryn-O3-polly-detect-only| 19:27:37
 sanitizer-x86_64-linux-autoconf| 18:54:22
 clang-cmake-armv7-a15-selfhost | 09:03:56
 clang-ppc64le-linux-multistage | 08:43:06
 clang-cmake-armv7-a15-selfhost-neon| 08:29:12
 clang-cmake-aarch64-global-isel| 08:16:10
 clang-ppc64be-linux-lnt| 08:13:14
 clang-cmake-aarch64-quick  | 07:56:17
 clang-ppc64be-linux| 07:23:50
 clang-s390x-linux-lnt  | 07:20:14
 llvm-mips-linux| 07:19:34
 sanitizer-ppc64le-linux| 07:11:33
 clang-ppc64le-linux| 07:03:44
 perf-x86_64-penryn-O3-polly-fast   | 06:29:34
 sanitizer-ppc64be-linux| 06:02:25
 polly-arm-linux| 06:02:09
 clang-ppc64be-linux-multistage | 05:54:40
 polly-amd64-linux  | 05:48:33
 clang-cmake-aarch64-lld| 05:34:08
 clang-native-arm-lnt   | 05:20:00
 sanitizer-x86_64-linux-android | 04:09:41
 clang-with-thin-lto-windows| 04:00:05
 sanitizer-x86_64-linux-bootstrap   | 03:52:11
 clang-x86-windows-msvc2015 | 03:39:56
 clang-s390x-linux-multistage   | 03:21:49
 lldb-windows7-android  | 03:13:33
 ubuntu-gcc7.1-werror   | 02:41:47
 clang-x86_64-linux-abi-test| 02:40:25
 clang-s390x-linux  | 02:38:05
 clang-cmake-aarch64-42vma  | 02:29:15
 lld-x86_64-darwin13| 02:25:33
 clang-cmake-armv7-a15-full | 02:14:41
 sanitizer-x86_64-linux | 02:12:30
 lldb-amd64-ninja-netbsd8   | 02:04:24
 lldb-x86-windows-msvc2015  | 02:01:55
 sanitizer-x86_64-linux-fuzzer  | 01:59:30
 clang-atom-d525-fedora-rel | 01:56:30
 llvm-hexagon-elf   | 01:50:01
 clang-x86_64-linux-selfhost-modules-2  | 01:37:31
 lldb-x86_64-darwin-13.4| 01:36:26
 clang-x86_64-linux-selfhost-modules| 01:24:39
 lldb-x86_64-ubuntu-14.04-android   | 01:18:00
 clang-cmake-armv7-a15  | 00:53:59
 clang-cmake-thumbv7-a15| 00:53:15
 clang-hexagon-elf  | 00:51:40
 lldb-x86_64-ubuntu-14.04-buildserver   | 00:51:29
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan  | 00:47:58
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 00:40:49
 lldb-x86_64-ubuntu-14.04-cmake | 00:38:01
 lld-x86_64-freebsd | 00:26:55
 lldb-amd64-ninja-freebsd11 | 00:20:13
 lld-x86_64-win7| 00:14:41
 lld-sphinx-docs| 00:09:34
 clang-tools-sphinx-docs| 00:09:31
 llvm-sphinx-docs   | 00:09:25
 clang-sphinx-docs  | 00:09:18
(69 rows)


"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):

buildername | builds |
changes | status_change_ratio

++-+
 clang-bpf-build| 72 |
11 |15.3
 clang-x64-n

[Lldb-commits] Buildbot numbers for the week of 08/20/2017 - 08/26/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for last the week of 08/20/2017 -
08/26/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

  buildername  |  was_red
---+--
 perf-x86_64-penryn-O3-polly   | 46:50:13
 perf-x86_64-penryn-O3-polly-detect-only   | 42:05:45
 perf-x86_64-penryn-O3-polly-fast  | 40:45:58
 clang-cmake-aarch64-full  | 22:45:50
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 21:12:15
 sanitizer-x86_64-linux-bootstrap  | 20:03:48
 clang-bpf-build   | 19:21:43
 clang-lld-x86_64-2stage   | 17:26:37
 sanitizer-ppc64le-linux   | 14:34:41
 ubuntu-gcc7.1-werror  | 13:10:34
 sanitizer-x86_64-linux| 12:09:21
 clang-with-lto-ubuntu | 11:37:41
 clang-with-thin-lto-ubuntu| 11:26:17
 sanitizer-ppc64be-linux   | 11:04:31
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 10:40:24
 clang-x64-ninja-win7  | 08:51:31
 llvm-clang-x86_64-expensive-checks-win| 08:11:23
 llvm-mips-linux   | 06:10:31
 clang-cmake-aarch64-quick | 05:50:13
 clang-cmake-armv7-a15-selfhost| 05:29:37
 clang-ppc64le-linux-multistage| 05:24:08
 clang-cmake-armv7-a15-selfhost-neon   | 04:19:49
 sanitizer-x86_64-linux-fast   | 04:17:41
 clang-cmake-aarch64-lld   | 04:00:21
 clang-s390x-linux-multistage  | 03:51:53
 sanitizer-x86_64-linux-fuzzer | 03:45:05
 clang-cmake-thumbv7-a15-full-sh   | 03:43:38
 clang-s390x-linux | 03:40:21
 clang-x86-windows-msvc2015| 03:33:19
 lldb-windows7-android | 03:15:49
 clang-x86_64-debian-fast  | 03:08:57
 clang-ppc64le-linux   | 03:03:10
 clang-cmake-aarch64-42vma | 02:57:57
 clang-ppc64be-linux   | 02:52:27
 clang-cuda-build  | 02:48:00
 clang-hexagon-elf | 02:47:35
 clang-atom-d525-fedora-rel| 02:45:35
 clang-ppc64be-linux-multistage| 02:45:04
 clang-cmake-armv7-a15 | 02:44:54
 clang-cmake-thumbv7-a15   | 02:44:46
 clang-cmake-armv7-a15-full| 02:38:57
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 02:37:22
 clang-x86_64-linux-selfhost-modules-2 | 02:37:00
 clang-ppc64le-linux-lnt   | 02:36:01
 clang-cmake-x86_64-sde-avx512-linux   | 02:34:18
 sanitizer-x86_64-linux-android| 02:24:01
 clang-cmake-x86_64-avx2-linux | 02:22:10
 clang-cmake-aarch64-global-isel   | 02:21:25
 clang-cmake-x86_64-avx2-linux-perf| 02:20:48
 clang-native-arm-lnt  | 02:12:07
 clang-s390x-linux-lnt | 02:04:20
 clang-with-thin-lto-windows   | 02:00:33
 lldb-x86_64-ubuntu-14.04-cmake| 01:58:18
 clang-ppc64be-linux-lnt   | 01:55:57
 clang-x86_64-linux-selfhost-modules   | 01:55:22
 clang-x86_64-linux-abi-test   | 01:50:57
 lld-x86_64-freebsd| 01:49:24
 sanitizer-x86_64-linux-autoconf   | 01:43:10
 lldb-x86_64-darwin-13.4   | 01:41:39
 sanitizer-windows | 01:21:34
 libcxx-libcxxabi-libunwind-arm-linux  | 01:20:24
 llvm-hexagon-elf  | 01:09:45
 lld-x86_64-win7   | 01:06:18
 lldb-x86_64-ubuntu-14.04-buildserver  | 00:50:4

[Lldb-commits] Buildbot numbers for the week of 08/27/2017 - 09/02/2017

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 08/27/2017 -
09/02/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the last week:

   buildername| was_red
--+-
 clang-cmake-x86_64-avx2-linux-perf   | 29:54:46
 sanitizer-ppc64be-linux  | 21:55:55
 sanitizer-x86_64-linux   | 19:49:02
 sanitizer-ppc64le-linux  | 19:27:52
 perf-x86_64-penryn-O3-polly-fast | 16:26:53
 clang-cmake-thumbv7-a15-full-sh  | 16:13:42
 clang-bpf-build  | 15:07:59
 sanitizer-x86_64-linux-bootstrap | 14:07:01
 sanitizer-x86_64-linux-android   | 13:13:14
 perf-x86_64-penryn-O3-polly  | 13:05:37
 polly-arm-linux  | 11:52:41
 sanitizer-x86_64-linux-fast  | 11:31:12
 lldb-amd64-ninja-netbsd8 | 09:33:25
 clang-atom-d525-fedora-rel   | 08:46:31
 clang-x86_64-linux-selfhost-modules-2| 07:33:59
 llvm-mips-linux  | 07:27:48
 clang-with-lto-ubuntu| 07:26:52
 llvm-clang-x86_64-expensive-checks-win   | 06:52:15
 clang-with-thin-lto-ubuntu   | 06:43:30
 clang-lld-x86_64-2stage  | 06:29:21
 clang-cmake-armv7-a15-selfhost   | 06:25:31
 clang-cmake-x86_64-avx2-linux| 05:53:36
 sanitizer-x86_64-linux-autoconf  | 04:22:14
 clang-ppc64be-linux  | 04:21:16
 clang-x86-windows-msvc2015   | 04:17:13
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 04:11:20
 lld-x86_64-darwin13  | 04:08:09
 clang-cmake-aarch64-lld  | 03:57:09
 clang-cuda-build | 03:52:32
 clang-cmake-aarch64-full | 03:49:03
 clang-x86_64-linux-selfhost-modules  | 03:47:02
 clang-cmake-x86_64-sde-avx512-linux  | 03:43:59
 ubuntu-gcc7.1-werror | 03:37:40
 clang-ppc64le-linux-multistage   | 03:30:57
 clang-ppc64le-linux-lnt  | 03:17:35
 clang-s390x-linux| 03:16:31
 clang-cmake-thumbv7-a15  | 03:16:17
 clang-ppc64be-linux-lnt  | 03:14:21
 clang-ppc64le-linux  | 03:03:39
 clang-cmake-armv7-a15| 03:02:57
 clang-hexagon-elf| 02:55:57
 llvm-hexagon-elf | 02:55:56
 clang-cmake-armv7-a15-full   | 02:49:32
 lldb-windows7-android| 02:44:56
 clang-with-thin-lto-windows  | 02:43:50
 clang-ppc64be-linux-multistage   | 02:40:08
 clang-cmake-aarch64-global-isel  | 02:32:34
 lld-x86_64-win7  | 02:30:28
 sanitizer-windows| 02:25:33
 clang-cmake-aarch64-quick| 02:22:42
 lldb-x86_64-darwin-13.4  | 02:12:27
 clang-x86_64-debian-fast | 02:07:27
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03   | 01:47:49
 clang-x64-ninja-win7 | 01:37:49
 lldb-x86-windows-msvc2015| 01:37:49
 lldb-x86_64-ubuntu-14.04-cmake   | 01:24:21
 sanitizer-x86_64-linux-fuzzer| 01:19:54
 clang-cmake-aarch64-42vma| 01:05:10
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast   | 01:01:31
 clang-x86_64-linux-abi-test  | 00:59:27
 lldb-amd64-ninja-freebsd11   | 00:57:59
 lldb-x86_64-ubuntu-14.04-buildserver | 00:52:46
 clang-native-arm-lnt | 00:50:47
 lld-x86_64-freebsd   | 00:38:17
 clang-cmake-armv7-a15-selfhost-neon  | 00:36:04
 polly-amd64-linux| 00:24:30
 llvm-sphinx-docs | 00:16:56
 clang-tools-sphinx-docs  | 00:05:46
 clang-sphinx-docs| 00:05:46
(69 rows)


"Status chang

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Leonard Mosescu via Phabricator via lldb-commits]

lemo created this revision.

The main change is to avoid setting the process state as running when debugging 
core/minidumps (details in the bug).

Also included a few small, related fixes around how the errors propagate in 
this case.


https://reviews.llvm.org/D37651

Files:
  include/lldb/Target/Process.h
  source/Commands/CommandObjectThread.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.h
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  source/Plugins/Process/minidump/ProcessMinidump.h
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -1615,6 +1615,15 @@
   LIBLLDB_LOG_PROCESS));
   if (log)
 log->Printf("Process::Resume -- locking run lock");
+  if (!CanResume()) {
+Status error;
+error.SetErrorStringWithFormat(
+"error: %s does not support resuming processes",
+GetPluginName().GetCString());
+if (log)
+  log->Printf("Process::Resume: -- plugin does not support resuming.");
+return error;
+  }
   if (!m_public_run_lock.TrySetRunning()) {
 Status error("Resume request failed - process still running.");
 if (log)
@@ -1629,6 +1638,15 @@
   LIBLLDB_LOG_PROCESS));
   if (log)
 log->Printf("Process::ResumeSynchronous -- locking run lock");
+  if (!CanResume()) {
+Status error;
+error.SetErrorStringWithFormat(
+"error: %s does not support resuming processes",
+GetPluginName().GetCString());
+if (log)
+  log->Printf("Process::Resume: -- plugin does not support resuming.");
+return error;
+  }
   if (!m_public_run_lock.TrySetRunning()) {
 Status error("Resume request failed - process still running.");
 if (log)
Index: source/Plugins/Process/minidump/ProcessMinidump.h
===
--- source/Plugins/Process/minidump/ProcessMinidump.h
+++ source/Plugins/Process/minidump/ProcessMinidump.h
@@ -65,6 +65,10 @@
 
   void RefreshStateAfterStop() override;
 
+  Status DoResume() override;
+
+  bool CanResume() const override { return false; }
+
   bool IsAlive() override;
 
   bool WarnBeforeDetach() const override;
Index: source/Plugins/Process/minidump/ProcessMinidump.cpp
===
--- source/Plugins/Process/minidump/ProcessMinidump.cpp
+++ source/Plugins/Process/minidump/ProcessMinidump.cpp
@@ -25,6 +25,7 @@
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
 
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Threading.h"
 
@@ -143,6 +144,10 @@
 
 Status ProcessMinidump::DoDestroy() { return Status(); }
 
+Status ProcessMinidump::DoResume() {
+  llvm::report_fatal_error("ProcessMinidump::DoResume() not supported");
+}
+
 void ProcessMinidump::RefreshStateAfterStop() {
   if (!m_active_exception)
 return;
Index: source/Plugins/Process/elf-core/ProcessElfCore.h
===
--- source/Plugins/Process/elf-core/ProcessElfCore.h
+++ source/Plugins/Process/elf-core/ProcessElfCore.h
@@ -84,11 +84,17 @@
 
   void RefreshStateAfterStop() override;
 
+  lldb_private::Status DoResume() override;
+
+  bool CanResume() const override { return false; }
+
   //--
   // Process Queries
   //--
   bool IsAlive() override;
 
+  bool WarnBeforeDetach() const override { return false; }
+
   //--
   // Process Memory
   //--
Index: source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -28,6 +28,7 @@
 #include "lldb/Utility/Log.h"
 
 #include "llvm/BinaryFormat/ELF.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Threading.h"
 
 #include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
@@ -219,7 +220,7 @@
   ArchSpec core_arch(m_core_module_sp->GetArchitecture());
   target_arch.MergeFrom(core_arch);
   GetTarget().SetArchitecture(target_arch);
- 
+
   SetUnixSignals(UnixSignals::Create(GetArchitecture()));
 
   // Ensure we found at least one thread that was stopped on a signal.
@@ -291,6 +292,10 @@
 
 Status ProcessElfCore::DoDestroy() { return Status(); }
 
+lldb_private::Status ProcessElfCore::DoResume() {
+  llvm::report_fatal_error("ProcessElfCore::DoResume() not supported");
+}
+
 //---

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Stephane Sezer via Phabricator via lldb-commits]

sas requested changes to this revision.
sas added a comment.
This revision now requires changes to proceed.

I think it would be cleaner/smaller if you didn't use pure-virtual functions, 
but instead you had `CanReseume()` return `false` in `Process.h`, and had a 
default implementation of `DoResume()`  that called 
`llvm::report_fatal_error()`.

Instead, here, you're defaulting `CanResume()` to `true` and forcing every 
child class to redefine as `false` and provide an error'ing implementation of 
`DoResume()`.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via Phabricator via lldb-commits]

jingham requested changes to this revision.
jingham added a comment.

This seems like an awkward solution to me.  Having CanResume and DoResume seems 
like it over-determines the problem.

Why wasn't it enough for DoResume to fail and the error to be propagated?

I'm also uncomfortable that this is making a possible code path for some 
programmer error to cause a fatal error in lldb (which we really want never to 
happen).  It would be much better to rely on the failure of DoResume.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

But whatever the solution, you should never use llvm::report_fatal_error.  It's 
fine to put in an lldb_assert which will assert when the error is hit in the 
test suite, but not in released lldb's.  After all, the worst that will happen 
if somebody working on lldb were to leave in a code path that called DoResume 
without CanResume is that the state of that core file target would be wrong.  
That is not an error worth taking down whoever happened to load the lldb 
framework into their program, or destroying all the other debug sessions or 
targets active in lldb.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth added a comment.

I think I agree with Jim that it would be better to propagate an error from 
DoResume than to introduce CanResume.  I could imagine situations where 
DoResume could fail for a reason that CanResume was unable to predict.  Having 
one path for handling failure to resume seems cleaner.

Also, consider adding a test.  I think it should be feasible to check the 
process state after attempting to resume and getting an error.




Comment at: source/Commands/CommandObjectThread.cpp:778
 
+  if(!error.Success()) {
+result.AppendMessage(error.AsCString());

Yeah, it looks like an oversight that the error was never checked, so this is 
good.

Make sure to run `git clang-format` to fix those little formatting nits (like 
the missing space after `if`.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [lldb] r312841 - Plugins: fix resolution ambiguity in PDB plugin

[Saleem Abdulrasool via lldb-commits]

Author: compnerd
Date: Fri Sep  8 17:13:49 2017
New Revision: 312841

URL: http://llvm.org/viewvc/llvm-project?rev=312841&view=rev
Log:
Plugins: fix resolution ambiguity in PDB plugin

A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespace due to the
`using namespace llvm;` and `using namespace lldb_private;`.  Explicitly
qualify the `Type` to resolve the ambiguity.  NFC

Modified:
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp

Modified: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp?rev=312841&r1=312840&r2=312841&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp Fri Sep  8 
17:13:49 2017
@@ -95,11 +95,11 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
 
 m_ast.SetHasExternalStorage(clang_type.GetOpaqueQualType(), true);
 
-return std::make_shared(type.getSymIndexId(), m_ast.GetSymbolFile(),
-  ConstString(udt->getName()), 
udt->getLength(),
-  nullptr, LLDB_INVALID_UID,
-  Type::eEncodingIsUID, decl, clang_type,
-  Type::eResolveStateForward);
+return std::make_shared(
+type.getSymIndexId(), m_ast.GetSymbolFile(),
+ConstString(udt->getName()), udt->getLength(), nullptr,
+LLDB_INVALID_UID, lldb_private::Type::eEncodingIsUID, decl, clang_type,
+lldb_private::Type::eResolveStateForward);
   } else if (auto enum_type = llvm::dyn_cast(&type)) {
 std::string name = enum_type->getName();
 lldb::Encoding encoding =
@@ -117,12 +117,12 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
   AddEnumValue(ast_enum, *enum_value);
 }
 
-return std::make_shared(type.getSymIndexId(), m_ast.GetSymbolFile(),
-  ConstString(name), bytes, nullptr,
-  LLDB_INVALID_UID, Type::eEncodingIsUID, decl,
-  ast_enum, Type::eResolveStateFull);
+return std::make_shared(
+type.getSymIndexId(), m_ast.GetSymbolFile(), ConstString(name), bytes,
+nullptr, LLDB_INVALID_UID, lldb_private::Type::eEncodingIsUID, decl,
+ast_enum, lldb_private::Type::eResolveStateFull);
   } else if (auto type_def = llvm::dyn_cast(&type)) {
-Type *target_type =
+lldb_private::Type *target_type =
 m_ast.GetSymbolFile()->ResolveTypeUID(type_def->getTypeId());
 std::string name = type_def->getName();
 uint64_t bytes = type_def->getLength();
@@ -133,16 +133,17 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
 m_ast.GetSymbolFile()->GetDeclContextForUID(target_type->GetID());
 CompilerType ast_typedef =
 m_ast.CreateTypedefType(target_ast_type, name.c_str(), 
target_decl_ctx);
-return std::make_shared(
+return std::make_shared(
 type_def->getSymIndexId(), m_ast.GetSymbolFile(), ConstString(name),
-bytes, nullptr, target_type->GetID(), Type::eEncodingIsTypedefUID, 
decl,
-ast_typedef, Type::eResolveStateFull);
+bytes, nullptr, target_type->GetID(),
+lldb_private::Type::eEncodingIsTypedefUID, decl, ast_typedef,
+lldb_private::Type::eResolveStateFull);
   } else if (auto func_sig = llvm::dyn_cast(&type)) {
 auto arg_enum = func_sig->getArguments();
 uint32_t num_args = arg_enum->getChildCount();
 std::vector arg_list(num_args);
 while (auto arg = arg_enum->getNext()) {
-  Type *arg_type =
+  lldb_private::Type *arg_type =
   m_ast.GetSymbolFile()->ResolveTypeUID(arg->getSymIndexId());
   // If there's some error looking up one of the dependent types of this
   // function signature, bail.
@@ -152,7 +153,7 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
   arg_list.push_back(arg_ast_type);
 }
 auto pdb_return_type = func_sig->getReturnType();
-Type *return_type =
+lldb_private::Type *return_type =
 
m_ast.GetSymbolFile()->ResolveTypeUID(pdb_return_type->getSymIndexId());
 // If there's some error looking up one of the dependent types of this
 // function signature, bail.
@@ -167,23 +168,24 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
 CompilerType func_sig_ast_type = m_ast.CreateFunctionType(
 return_ast_type, &arg_list[0], num_args, false, type_quals);
 
-return std::make_shared(
+return std::make_shared(
 func_sig->getSymIndexId(), m_ast.GetSymbolFile(), ConstString(), 0,
-nullptr, LLDB_INVALID_UID, Type::eEncodingIsUID, decl,
-func_sig_ast_type, Type::eResolveStateFull);
+nullptr, LLDB_INVALID_UID, lldb_private::Type::eEncodingIsUID, decl,
+func_sig_ast_type, lldb_private::Type::eResolveStateFul

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Leonard Mosescu via Phabricator via lldb-commits]

lemo added a comment.

Thanks everyone for the feedback.

I see a common question is why doesn't DoResume() fail-fast itself, or why 
don't the callers propagate the error. It's a good question, since the 
knowledge if a subclass can resume or not is almost codified in there. The 
problem is that the state is changed prior to calling DoResume() - see 
Process::Resume(), ... m_public_run_lock.TrySetRunning() ..., thus the need for 
an earlier check.

@sas: Yes, a flip approach is possible and I briefly considered the default 
CanResume() to return false exactly as you're suggesting. The downside is a 
more brittle composability - subclasses can't call the base implementation, 
which is usually a reasonable expectation if one wants to build additional 
functionality on top of the base one. So I prefer the version I sent out, but I 
could be persuaded either way.

@jingham: 1. I'm not sure I understand the comment about "over-determining the 
problem", can you please elaborate? If this is about having two methods instead 
of just DoResume(), I explained above the rationale. 2. Sorry, but defensive 
programming is exactly the wrong thing, and the root cause of what I'm fixing 
here. If the internal state is inconsistent the _only_ valid solution is to 
fail-fast. I've seen people arguing around this for everything from embedded 
systems to distributed services and trying to limp along pretending things are 
not too bad only lead to more pain.

@amccarth: I agree that DoResume() can fail for reasons that CanResume() can't 
predict, and that's prefectly fine - the error is returned (and hopefully it's 
propagated correctly). Having DoResume() called for a core or minidump is never 
ok though, and that's the fail-fast path.

(thanks' for the clang-format tip, I'll do that shortly)

@


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

lldb is a library used in other programs (Xcode, VSCode etc) and it can support 
many simultaneous debug sessions and each debug session can support many 
simultaneous targets.  Unless this failure is going to make all the other debug 
sessions fail, and the other target sessions fail and cause the app which has 
loaded us to fail, we have no business crashing.

I know there is debate about this one side and another but for lldb this is a 
settled issue.  Unless you really are in a state where the world is about to 
come crashing down around you, you can't raise a fatal error in lldb.  And in 
this case, the world is only very minorly strange, so it is certainly not 
appropriate.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

As for the overdetermined remark, it's what you suspect, that you are now 
asking two questions to get one answer, did the resume succeed.  If the resume 
didn't succeed the state should be set back to stopped no matter why it didn't 
succeed.  So you are fixing only one specific case only.  Is it really not 
possible to either hold off on changing the process state till you've gotten 
back the result from DoResume, or correct the state after the fact?  That seems 
the obviously correct fix here.


https://reviews.llvm.org/D37651



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

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

And I don't understand your answer to Adrian.  In the case of core files, 
DoResume is clearly failing so if the error WERE handled correctly, why would 
there be any work needed?


https://reviews.llvm.org/D37651



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

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Zachary Turner via lldb-commits]

On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:

>
> I know there is debate about this one side and another but for lldb this
> is a settled issue.  Unless you really are in a state where the world is
> about to come crashing down around you, you can't raise a fatal error in
> lldb.  And in this case, the world is only very minorly strange, so it is
> certainly not appropriate.


I don't agree that this is a settled issue in LLDB.

For starters, clang already does this, and LLDB links against libclang.

Second, a year or so ago, i recall Greg saying that LLDB now runs out of
process in Xcode, which should make this a non issue.

Finally, by allowing inconsistent state to propagate through the code you
are only hurting yourself, as you're ultimately not preventing any
crashes.  It'll just crash later when you de reference a null pointer or
read some corrupt memory.  Furthermore, it actually increases the
likelihood of introducing bugs, due to the added complexity and technical
debt introduced by untested code paths

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

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Zachary Turner via lldb-commits]

Note that if something originates from user input, then i agree there's no
excuse for a fail fast. But after all the inputs have been sanitized, I
think it's fine to fast fail
On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner  wrote:

> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>>
>> I know there is debate about this one side and another but for lldb this
>> is a settled issue.  Unless you really are in a state where the world is
>> about to come crashing down around you, you can't raise a fatal error in
>> lldb.  And in this case, the world is only very minorly strange, so it is
>> certainly not appropriate.
>
>
> I don't agree that this is a settled issue in LLDB.
>
> For starters, clang already does this, and LLDB links against libclang.
>
> Second, a year or so ago, i recall Greg saying that LLDB now runs out of
> process in Xcode, which should make this a non issue.
>
> Finally, by allowing inconsistent state to propagate through the code you
> are only hurting yourself, as you're ultimately not preventing any
> crashes.  It'll just crash later when you de reference a null pointer or
> read some corrupt memory.  Furthermore, it actually increases the
> likelihood of introducing bugs, due to the added complexity and technical
> debt introduced by untested code paths
>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jim Ingham via lldb-commits]

Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused much 
pain to lldb.  We don’t control that behavior and so are resigned to some 
continued suffering along those lines - though it seems like Lang is going to 
do a much cleaner job of handling problems in the new ORC JIT which will remove 
some significant source of that pain.  And we have no intention of exacerbating 
it in areas we have more control over.  That has been both Greg and my strong 
opinion since we started the work on lldb.  Greg can weigh in on whether he has 
changed his mind about this, I have not.

BTW, the fact that lldb can run out of process doesn’t make it that much 
better.  Because lldb caches the parse of object files from debugger to 
debugger it is much more efficient to keep one out of process lldb session 
running per targeted OS.  So Xcode runs one for all the Native processes and 
one for each iOS device.  But that means that you are still going to take down 
all the debug sessions for that target when the debugger goes down.  So still 
quite undesirable.

Jim


> On Sep 8, 2017, at 7:18 PM, Zachary Turner  wrote:
> 
> Note that if something originates from user input, then i agree there's no 
> excuse for a fail fast. But after all the inputs have been sanitized, I think 
> it's fine to fast fail
> On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner  > wrote:
> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator 
> mailto:revi...@reviews.llvm.org>> wrote:
> 
> I know there is debate about this one side and another but for lldb this is a 
> settled issue.  Unless you really are in a state where the world is about to 
> come crashing down around you, you can't raise a fatal error in lldb.  And in 
> this case, the world is only very minorly strange, so it is certainly not 
> appropriate.
> 
> I don't agree that this is a settled issue in LLDB.  
> 
> For starters, clang already does this, and LLDB links against libclang.
> 
> Second, a year or so ago, i recall Greg saying that LLDB now runs out of 
> process in Xcode, which should make this a non issue.
> 
> Finally, by allowing inconsistent state to propagate through the code you are 
> only hurting yourself, as you're ultimately not preventing any crashes.  
> It'll just crash later when you de reference a null pointer or read some 
> corrupt memory.  Furthermore, it actually increases the likelihood of 
> introducing bugs, due to the added complexity and technical debt introduced 
> by untested code paths

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

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jason Molenda via lldb-commits]

Also keep in mind that debug sessions have a tendency to be long lived.  I may 
be working through a problem for half an hour -- or this may be the one rare 
instance where a bug reproduces -- and crashing because some bogus piece of 
debug info that I don't care about is invalid is not acceptable.  I've gotten 
those bug reports, where someone has spent all day getting to just the point 
where they have the problem in front of them, only to have the debugger crash, 
and they are rightfully enraged at the debugger for this.

An interactive tool like the debugger cannot use a model where asserting is 
acceptable.  Even if lldb is out-of-process, you're losing all of the work 
you'd done until then, and complex bugs can involve extraordinarily long 
running debug sessions.  The fact that llvm/clang can assert out from under us 
is to the detriment of lldb's quality. 

J

> On Sep 8, 2017, at 7:41 PM, Jim Ingham via lldb-commits 
>  wrote:
> 
> Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused 
> much pain to lldb.  We don’t control that behavior and so are resigned to 
> some continued suffering along those lines - though it seems like Lang is 
> going to do a much cleaner job of handling problems in the new ORC JIT which 
> will remove some significant source of that pain.  And we have no intention 
> of exacerbating it in areas we have more control over.  That has been both 
> Greg and my strong opinion since we started the work on lldb.  Greg can weigh 
> in on whether he has changed his mind about this, I have not.
> 
> BTW, the fact that lldb can run out of process doesn’t make it that much 
> better.  Because lldb caches the parse of object files from debugger to 
> debugger it is much more efficient to keep one out of process lldb session 
> running per targeted OS.  So Xcode runs one for all the Native processes and 
> one for each iOS device.  But that means that you are still going to take 
> down all the debug sessions for that target when the debugger goes down.  So 
> still quite undesirable.
> 
> Jim
> 
> 
>> On Sep 8, 2017, at 7:18 PM, Zachary Turner  wrote:
>> 
>> Note that if something originates from user input, then i agree there's no 
>> excuse for a fail fast. But after all the inputs have been sanitized, I 
>> think it's fine to fast fail
>> On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner  wrote:
>> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator 
>>  wrote:
>> 
>> I know there is debate about this one side and another but for lldb this is 
>> a settled issue.  Unless you really are in a state where the world is about 
>> to come crashing down around you, you can't raise a fatal error in lldb.  
>> And in this case, the world is only very minorly strange, so it is certainly 
>> not appropriate.
>> 
>> I don't agree that this is a settled issue in LLDB.  
>> 
>> For starters, clang already does this, and LLDB links against libclang.
>> 
>> Second, a year or so ago, i recall Greg saying that LLDB now runs out of 
>> process in Xcode, which should make this a non issue.
>> 
>> Finally, by allowing inconsistent state to propagate through the code you 
>> are only hurting yourself, as you're ultimately not preventing any crashes.  
>> It'll just crash later when you de reference a null pointer or read some 
>> corrupt memory.  Furthermore, it actually increases the likelihood of 
>> introducing bugs, due to the added complexity and technical debt introduced 
>> by untested code paths
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Jason Molenda via lldb-commits]

Just to comment on one aside from earlier, about the fact that Apple moved lldb 
out of process from Xcode.  This was necessitated by some swift support issues, 
but it's true that the fact that lldb crashing no longer took down Xcode was a 
big plus to moving lldb out of process.  This shouldn't be seen as a model to 
be emulated, but a shortcoming and failure of lldb as a mature piece of 
software.  We can't provide this great debugger API that we encourage people to 
adopt and then say 'Well yeah sure but if you don't want your app crashing out 
from under you, better not use that'.  Apple would have had to move lldb out of 
process regardless of this issue, but the fact that there had been discussions 
about moving lldb out of process BECAUSE of the crashing for a long time is a 
truth that pains me.


> On Sep 8, 2017, at 8:19 PM, Jason Molenda via lldb-commits 
>  wrote:
> 
> Also keep in mind that debug sessions have a tendency to be long lived.  I 
> may be working through a problem for half an hour -- or this may be the one 
> rare instance where a bug reproduces -- and crashing because some bogus piece 
> of debug info that I don't care about is invalid is not acceptable.  I've 
> gotten those bug reports, where someone has spent all day getting to just the 
> point where they have the problem in front of them, only to have the debugger 
> crash, and they are rightfully enraged at the debugger for this.
> 
> An interactive tool like the debugger cannot use a model where asserting is 
> acceptable.  Even if lldb is out-of-process, you're losing all of the work 
> you'd done until then, and complex bugs can involve extraordinarily long 
> running debug sessions.  The fact that llvm/clang can assert out from under 
> us is to the detriment of lldb's quality. 
> 
> J
> 
>> On Sep 8, 2017, at 7:41 PM, Jim Ingham via lldb-commits 
>>  wrote:
>> 
>> Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused 
>> much pain to lldb.  We don’t control that behavior and so are resigned to 
>> some continued suffering along those lines - though it seems like Lang is 
>> going to do a much cleaner job of handling problems in the new ORC JIT which 
>> will remove some significant source of that pain.  And we have no intention 
>> of exacerbating it in areas we have more control over.  That has been both 
>> Greg and my strong opinion since we started the work on lldb.  Greg can 
>> weigh in on whether he has changed his mind about this, I have not.
>> 
>> BTW, the fact that lldb can run out of process doesn’t make it that much 
>> better.  Because lldb caches the parse of object files from debugger to 
>> debugger it is much more efficient to keep one out of process lldb session 
>> running per targeted OS.  So Xcode runs one for all the Native processes and 
>> one for each iOS device.  But that means that you are still going to take 
>> down all the debug sessions for that target when the debugger goes down.  So 
>> still quite undesirable.
>> 
>> Jim
>> 
>> 
>>> On Sep 8, 2017, at 7:18 PM, Zachary Turner  wrote:
>>> 
>>> Note that if something originates from user input, then i agree there's no 
>>> excuse for a fail fast. But after all the inputs have been sanitized, I 
>>> think it's fine to fast fail
>>> On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner  wrote:
>>> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator 
>>>  wrote:
>>> 
>>> I know there is debate about this one side and another but for lldb this is 
>>> a settled issue.  Unless you really are in a state where the world is about 
>>> to come crashing down around you, you can't raise a fatal error in lldb.  
>>> And in this case, the world is only very minorly strange, so it is 
>>> certainly not appropriate.
>>> 
>>> I don't agree that this is a settled issue in LLDB.  
>>> 
>>> For starters, clang already does this, and LLDB links against libclang.
>>> 
>>> Second, a year or so ago, i recall Greg saying that LLDB now runs out of 
>>> process in Xcode, which should make this a non issue.
>>> 
>>> Finally, by allowing inconsistent state to propagate through the code you 
>>> are only hurting yourself, as you're ultimately not preventing any crashes. 
>>>  It'll just crash later when you de reference a null pointer or read some 
>>> corrupt memory.  Furthermore, it actually increases the likelihood of 
>>> introducing bugs, due to the added complexity and technical debt introduced 
>>> by untested code paths
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

[Zachary Turner via lldb-commits]

On Fri, Sep 8, 2017 at 8:19 PM Jason Molenda  wrote:

> Also keep in mind that debug sessions have a tendency to be long lived.  I
> may be working through a problem for half an hour -- or this may be the one
> rare instance where a bug reproduces -- and crashing because some bogus
> piece of debug info that I don't care about is invalid is not acceptable.
> I've gotten those bug reports, where someone has spent all day getting to
> just the point where they have the problem in front of them, only to have
> the debugger crash, and they are rightfully enraged at the debugger for
> this.
>
> An interactive tool like the debugger cannot use a model where asserting
> is acceptable.  Even if lldb is out-of-process, you're losing all of the
> work you'd done until then, and complex bugs can involve extraordinarily
> long running debug sessions.  The fact that llvm/clang can assert out from
> under us is to the detriment of lldb's quality.
>
> J

Fwiw i think we all agree that it shouldn't crash.  What we disagree on is
the best way of making it crash less.  It's easy to see why someone would
argue that adding an assert increases the incidence of crashes.  I mean on
the surface it seems ridiculous to argue otherwise.

But otherwise is precisely what we all continue to argue.

Your position is that by going out of your way to avoid crashes, it will
crash less and be more stable.  Pretty intuitive position if I'm being
honest.  But I don't agree.

I think you are trading short term metrics for long term technical debt.

You fix one crash by adding a null check, without figuring out why null
ever got in there in the first place.

You get fewer bug reports because instead of crashing, which would
hopefully trigger some automatic crash uploader in Xcode that automatically
files a rdar, you just never find out about the bug in the first place.

You introduce even more bugs, because when you go to edit a function, its
complexity and branching is through the roof, and you overlook something
some corner case.

You have less test coverage because you introduce another untested branch
in the code, reducing the already abysmal code coverage even further.

The way to reduce crashing is to *increase* the code coverage of your test
suite.  That is the solution.  And you don't do that by adding null checks
everywhere, you do it by removing them and asserting.

Yes, it means Xcode might crash.  But you know the bug exists!  How many
bugs are out there right now that nobody even knows about because they are
hidden by a null pointer check and instead of the user trying to figure out
what's going and filing a bug report, they just give up and use gdb
instead.  That's one more person you're never going to get back.

Crashing Xcode is annoying, but it's fixable.  But when your technical debt
is going up and to the right, and your test coverage is going down and to
the right, that's an existential threat to the project .

Btw, i still don't understand why asserts cause anything to crash, given
that they're supposed to be turned off in a release build
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits