On 02/21/2024 03:52 AM, ci_notify@linaro.org wrote:
If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
We can see "Operation not permitted" in the log info, please try one of the following processes to test: (1) set ptrace_scope as 0 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope $ make check-gdb TESTS="gdb.threads/attach-many-short-lived-threads.exp" (2) use sudo $ sudo make check-gdb TESTS="gdb.threads/attach-many-short-lived-threads.exp"
Thanks, Tiezhu
On Feb 21, 2024, at 05:46, Tiezhu Yang yangtiezhu@loongson.cn wrote:
On 02/21/2024 03:52 AM, ci_notify@linaro.org wrote:
If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
We can see "Operation not permitted" in the log info, please try one of the following processes to test: (1) set ptrace_scope as 0 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope $ make check-gdb TESTS="gdb.threads/attach-many-short-lived-threads.exp"
Hi Tiezhu,
We already use the above approach for testing. Also, our CI reports only regressions, not all failures, and the environment, generally, does not change whether the test passes or fails.
The problem appears to be the fact that gdb.threads/attach-many-short-lived-threads.exp tests are flaky, and detected as such in [1] -- search for "delete all breakpoints". However, because your patch renames the tests, the flaky entries do not match, and failures are seen as regressions.
Do the "gdb.threads/attach-many-short-lived-threads.exp: iter <N>" tests pass reliably for you?
Thanks,
[1] https://ci.linaro.org/job/tcwg_gdb_check--master-arm-precommit/1725/artifact...
-- Maxim Kuvyrkov https://www.linaro.org
On 02/21/2024 03:16 PM, Maxim Kuvyrkov wrote:
On Feb 21, 2024, at 05:46, Tiezhu Yang yangtiezhu@loongson.cn wrote:
On 02/21/2024 03:52 AM, ci_notify@linaro.org wrote:
If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
We can see "Operation not permitted" in the log info, please try one of the following processes to test: (1) set ptrace_scope as 0 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope $ make check-gdb TESTS="gdb.threads/attach-many-short-lived-threads.exp"
Hi Tiezhu,
We already use the above approach for testing. Also, our CI reports only regressions, not all failures, and the environment, generally, does not change whether the test passes or fails.
The problem appears to be the fact that gdb.threads/attach-many-short-lived-threads.exp tests are flaky, and detected as such in [1] -- search for "delete all breakpoints". However, because your patch renames the tests, the flaky entries do not match, and failures are seen as regressions.
OK, I see. Are there any regressions tested with the following change on top of the patch?
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 7357d56f89a..7e14de44609 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -373,7 +373,7 @@ proc delete_breakpoints {} { # set timeout 100
- set msg "delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints" + set msg "delete all breakpoints in delete_breakpoints" set deleted 0 gdb_test_multiple "delete breakpoints" "$msg" { -re "Delete all breakpoints, watchpoints, tracepoints, and catchpoints.*y or n.*$" {
If it is OK for you to avoid regressions, I will squash the above change in the patch and then send a new version.
Thanks, Tiezhu
On Feb 21, 2024, at 12:44, Tiezhu Yang yangtiezhu@loongson.cn wrote:
On 02/21/2024 03:16 PM, Maxim Kuvyrkov wrote:
On Feb 21, 2024, at 05:46, Tiezhu Yang yangtiezhu@loongson.cn wrote:
On 02/21/2024 03:52 AM, ci_notify@linaro.org wrote:
If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
We can see "Operation not permitted" in the log info, please try one of the following processes to test: (1) set ptrace_scope as 0 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope $ make check-gdb TESTS="gdb.threads/attach-many-short-lived-threads.exp"
Hi Tiezhu,
We already use the above approach for testing. Also, our CI reports only regressions, not all failures, and the environment, generally, does not change whether the test passes or fails.
The problem appears to be the fact that gdb.threads/attach-many-short-lived-threads.exp tests are flaky, and detected as such in [1] -- search for "delete all breakpoints". However, because your patch renames the tests, the flaky entries do not match, and failures are seen as regressions.
OK, I see. Are there any regressions tested with the following change on top of the patch?
Hi Tiezhu,
What I meant is that there are no real regressions from your patch and you can ignore the report.
-- Maxim Kuvyrkov https://www.linaro.org
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 7357d56f89a..7e14de44609 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -373,7 +373,7 @@ proc delete_breakpoints {} { # set timeout 100
- set msg "delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints"
- set msg "delete all breakpoints in delete_breakpoints" set deleted 0 gdb_test_multiple "delete breakpoints" "$msg" { -re "Delete all breakpoints, watchpoints, tracepoints, and catchpoints.*y or n.*$" {
If it is OK for you to avoid regressions, I will squash the above change in the patch and then send a new version.
Thanks, Tiezhu
linaro-toolchain@lists.linaro.org
-
Maxim Kuvyrkov -
Tiezhu Yang