Hi!
This seems to be an issue with your testing infrastructure. These patches have not touched anything that isn't related to record-full so there's no way they could be causing failures in gdb.arch tests. I guess this test is no longer reliable.
Hi Guinevere,
Linaro CI has very consistently identified same failures in patches 1/8, 2/8, 3/8, 4/8, and 5/8 of your patch series for both aarch32-linux and aarch64-linux targets. Starting with patch 6/8 testing passes for both aarch32-linux and aarch64-linux. Also, no other patches in [1] show same failure pattern as your patch series.
It's possible that there is a problem with Linaro CI, but your patch [2] seems like a likely culprit. Maybe it's missing a part that's later added in 6/8?
Please let me know if it still looks like a CI failure, and I'll investigate more.
Thanks!
[1] https://patchwork.sourceware.org/project/gdb/list/ [2] https://patchwork.sourceware.org/project/gdb/patch/20260602143342.12245-2-gu...
-- Maxim Kuvyrkov https://www.linaro.org
On Jun 8, 2026, at 16:26, Guinevere Larsen via linaro-toolchain linaro-toolchain@lists.linaro.org wrote:
Hi!
This seems to be an issue with your testing infrastructure. These patches have not touched anything that isn't related to record-full so there's no way they could be causing failures in gdb.arch tests. I guess this test is no longer reliable.
-- Cheers, Guinevere Larsen It/she
On 6/7/26 3:44 AM, ci_notify@linaro.org wrote:
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In gdb_check master-arm, after: | 3 patches in gdb | Patchwork URL: https://patchwork.sourceware.org/patch/136305 | 1f3856ef4e9 [PATCH v4 3/8] gdb/record: remove record_full_insn_num | 9165d18a941 [PATCH v4 2/8] gdb/record: factor out reading and writing the execution log to corefile | 85ad6ec91da [PATCH v4 1/8] gdb/record: Refactor record history | ... applied on top of baseline commit: | 4562eab73d3 Automatic date update in version.in
Produces 171 regressions: | | regressions.sum: | Running gdb:gdb.arch/skip-prologue.exp ... | FAIL: gdb.arch/skip-prologue.exp: f2: $\bp_addr == $\prologue_end_addr (skipped too much) | FAIL: gdb.arch/skip-prologue.exp: f4: $\bp_addr == $\prologue_end_addr (skipped too much) | Running gdb:gdb.arch/thumb2-it.exp ... | FAIL: gdb.arch/thumb2-it.exp: it_3, stepi 3 | ... and 187 more
Used configuration : *CI config* tcwg_gdb_check master-arm *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
The full lists of regressions and improvements as well as configure and make commands are in
The list of [ignored] baseline and flaky failures are in
Current build : http://54.172.246.49:9090/jobs/tcwg_gdb_check--master-arm-precommit/builds/1... Reference build : http://54.172.246.49:9090/jobs/tcwg_gdb_check--master-arm-build/builds/10211...
Warning: we do not enable maintainer-mode nor automatically update generated files, which may lead to failures if the patch modifies the master files.
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
Maxim Kuvyrkov via linaro-toolchain linaro-toolchain@lists.linaro.org writes:
Linaro CI has very consistently identified same failures in patches 1/8, 2/8, 3/8, 4/8, and 5/8 of your patch series for both aarch32-linux and aarch64-linux targets. Starting with patch 6/8 testing passes for both aarch32-linux and aarch64-linux. Also, no other patches in [1] show same failure pattern as your patch series.
It's possible that there is a problem with Linaro CI, but your patch [2] seems like a likely culprit. Maybe it's missing a part that's later added in 6/8?
Please let me know if it still looks like a CI failure, and I'll investigate more.
I think there's something wrong with the reported list of regressions.
If I run validate_failures.py manually from the precommit job's artifacts.precommit directory I get a shorter list of regressions:
$ validate_failures.py --manifest=06-check_regression/baseline.xfail --results=<(unxz -c sumfiles/gdb.sum.xz) Manifest: 06-check_regression/baseline.xfail Getting actual results from user-provided results /proc/self/fd/11
Unexpected results in this build (new failures) === gdb tests ===
Running gdb:gdb.base/gdb-sigterm.exp ... UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes FAIL: gdb.base/gdb-sigterm.exp: pass=0: expect eof (GDB internal error)
Running gdb:gdb.mi/mi-break.exp ... FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_ignore_count: insert breakpoint with ignore count at callme (unexpected output) FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_tbreak_creation_and_listing: delete temp breakpoints (unexpected output) FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_tbreak_creation_and_listing: list of breakpoints (timeout)
Running gdb:gdb.reverse/solib-precsave.exp ... FAIL: gdb.reverse/solib-precsave.exp: reverse-next first shr1 FAIL: gdb.reverse/solib-precsave.exp: reverse-next generic FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-next second shr1 FAIL: gdb.reverse/solib-precsave.exp: reverse-next third shr1 FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two
Running gdb:gdb.threads/detach-step-over.exp ... FAIL: gdb.threads/detach-step-over.exp: breakpoint-condition-evaluation=host: target-non-stop=on: non-stop=on: displaced=off: test_detach_command: iter 3: attach (GDB internal error)
Running gdb:gdb.threads/interrupt-while-step-over.exp ... FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=off: iter=19: wait for stops (timeout) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=off: iter=5: wait for stops (timeout)
Running gdb:gdb.threads/next-fork-exec-other-thread.exp ... FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to for loop (timeout) FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=3: next to for loop (timeout) FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=7: next to for loop (timeout) FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to other line (timeout) FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=0: next to other line (timeout) FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=1: next to for loop (timeout)
Running gdb:gdb.threads/next-fork-other-thread.exp ... FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=10: next to for loop (timeout) FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=5: next to for loop (timeout) FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=3: next to other line (timeout)
Running gdb:gdb.threads/process-dies-while-detaching.exp ... FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue to breakpoint: _exit (timeout) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: detach: continue to breakpoint: _exit (timeout) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint:sw: continue to breakpoint: _exit (timeout)
[ Snipped the rest of the output for brevity, but the list of potential regressions above is complete. ]
Guinevere,
The FAILs in gdb.threads/ are almost surely regressions not yet marked as such by our CI. I also see the gdb.base/gdb-sigterm.exp and gdb.mi/mi-break.exp FAILs on current trunk so they're also false positives.
OTOH gdb.reverse/solib-precsave.exp passes fully on trunk so it looks like a real regression.
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
The FAILs in gdb.threads/ are almost surely regressions not yet marked as such by our CI. I also see the gdb.base/gdb-sigterm.exp and gdb.mi/mi-break.exp FAILs on current trunk so they're also false positives.
Sorry, I mischecked mi-break.exp. It passes fully on current trunk. It's common for MI tests to be flaky though, so it could also be a case of a flaky test not yet flagged as such by our CI.
On 6/9/26 12:52 AM, Thiago Jung Bauermann wrote:
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
The FAILs in gdb.threads/ are almost surely regressions not yet marked as such by our CI. I also see the gdb.base/gdb-sigterm.exp and gdb.mi/mi-break.exp FAILs on current trunk so they're also false positives.
Sorry, I mischecked mi-break.exp. It passes fully on current trunk. It's common for MI tests to be flaky though, so it could also be a case of a flaky test not yet flagged as such by our CI.
Yeah, based on what is changed by the test, there's nothing outside of gdb.reverse that would be affected by this test
the solib-precsave.exp failures are definitely concerning though, thanks for pointing those out!
Hi Guinevere,
We've found and fixed an issue in Linaro CI.
The problem was that when a regression is detected (solib-precsave.exp failures in this case), the report also included pre-existing known failures in the regression list. So your 1/8 patch indeed has an issue that needs fixing, but only solib-precsave.exp failures are actual regressions.
Thanks for bringing this issue to our attention!
Kind regards,
-- Maxim Kuvyrkov https://www.linaro.org
On Jun 9, 2026, at 14:39, Guinevere Larsen guinevere@redhat.com wrote:
On 6/9/26 12:52 AM, Thiago Jung Bauermann wrote:
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
The FAILs in gdb.threads/ are almost surely regressions not yet marked as such by our CI. I also see the gdb.base/gdb-sigterm.exp and gdb.mi/mi-break.exp FAILs on current trunk so they're also false positives.
Sorry, I mischecked mi-break.exp. It passes fully on current trunk. It's common for MI tests to be flaky though, so it could also be a case of a flaky test not yet flagged as such by our CI.
Yeah, based on what is changed by the test, there's nothing outside of gdb.reverse that would be affected by this test
the solib-precsave.exp failures are definitely concerning though, thanks for pointing those out!
-- Cheers, Guinevere Larsen It/she
Thank you for fixing and maintaining the CI! and highlighting the issue in patch 1/8
linaro-toolchain@lists.linaro.org
-
Guinevere Larsen -
Maxim Kuvyrkov -
Thiago Jung Bauermann