I think some issue has happened in the CI. Both this and 2 patches I've sent to the mailing list (one that changes no code, only the SECURITY.txt file) say that I've introduced regressions, yet the relevant test only has "no file ID for <hex number>".
Can you double check what's going on?
Hi Guinevere,
On Mon, 23 Sept 2024 at 14:05, Guinevere Larsen guinevere@redhat.com wrote:
I think some issue has happened in the CI. Both this and 2 patches I've sent to the mailing list (one that changes no code, only the SECURITY.txt file) say that I've introduced regressions, yet the relevant test only has "no file ID for <hex number>".
Can you double check what's going on?
I've noticed this patch: https://sourceware.org/pipermail/gdb-patches/2024-September/211848.html
It seems the test build for your patch started before this fix was pushed, so I think it should now be OK again.
Thanks,
Christophe
-- Cheers, Guinevere Larsen She/Her/Hers
On 9/23/24 5:18 AM, ci_notify@linaro.org wrote:
Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
We understand that it might be difficult to find the necessary logs or reproduce the issue locally. If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
In gdb_check master-arm after:
| gdb patch https://patchwork.sourceware.org/patch/97698 | Author: Guinevere Larsen blarsen@redhat.com | Date: Thu Sep 19 09:42:04 2024 -0300 | | gdb/testsuite: rework bp-cond-failure to not depend on inlining | | The test gdb.base/bp-cond-failure is implicitly expecting that the | function foo will be inlined twice and gdb will be able to find 2 | locations to place a breakpoint. When clang is used, gdb only finds | one location which causes the test to fail. Since the test is not | worried about handling breakpoints on inlined functions, but rather on | ... 11 lines of the commit log omitted. | ... applied on top of baseline commit: | d3acf3d759d Rename tui_suppress_output
FAIL: 1 regressions: 1 improvements
regressions.sum: === gdb tests ===
Running gdb:gdb.base/return.exp ... ERROR: no fileid for 5a8f76db3a07
improvements.sum: === gdb tests ===
Running gdb:gdb.base/return.exp ... ERROR: no fileid for a55c644d3a50
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
The configuration of this build is: CI config tcwg_gdb_check master-arm
-----------------8<--------------------------8<--------------------------8<-------------------------- The information below can be used to reproduce a debug environment:
Current build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-precommit/3013/artifact... Reference build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/1786/artifact/art...
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
On 9/23/24 10:33 AM, Christophe Lyon wrote:
Hi Guinevere,
On Mon, 23 Sept 2024 at 14:05, Guinevere Larsen guinevere@redhat.com wrote:
I think some issue has happened in the CI. Both this and 2 patches I've sent to the mailing list (one that changes no code, only the SECURITY.txt file) say that I've introduced regressions, yet the relevant test only has "no file ID for <hex number>".
Can you double check what's going on?
I've noticed this patch: https://sourceware.org/pipermail/gdb-patches/2024-September/211848.html
It seems the test build for your patch started before this fix was pushed, so I think it should now be OK again.
Ah, that's good. But I still think there is a CI bug in there. Both before and after were errors, it's just that the file ID hex number was different. In this situation, I think CI shouldn't say that there is an issue with my patch, at most that there is an issue with the testsuite.
On Mon, 23 Sept 2024 at 15:44, Guinevere Larsen guinevere@redhat.com wrote:
On 9/23/24 10:33 AM, Christophe Lyon wrote:
Hi Guinevere,
On Mon, 23 Sept 2024 at 14:05, Guinevere Larsen guinevere@redhat.com wrote:
I think some issue has happened in the CI. Both this and 2 patches I've sent to the mailing list (one that changes no code, only the SECURITY.txt file) say that I've introduced regressions, yet the relevant test only has "no file ID for <hex number>".
Can you double check what's going on?
I've noticed this patch: https://sourceware.org/pipermail/gdb-patches/2024-September/211848.html
It seems the test build for your patch started before this fix was pushed, so I think it should now be OK again.
Ah, that's good. But I still think there is a CI bug in there. Both before and after were errors, it's just that the file ID hex number was different. In this situation, I think CI shouldn't say that there is an issue with my patch, at most that there is an issue with the testsuite.
Indeed, we have room for improvement here :-) The reason it's not detected as a flaky test is that it's not FAIL <-> PASS followed by always the same text (aka test name), but always ERROR followed by a varying text.
We'll try to handle this case better.
Thanks,
Christophe
-- Cheers, Guinevere Larsen She/Her/Hers
Thanks,
Christophe
-- Cheers, Guinevere Larsen She/Her/Hers
On 9/23/24 5:18 AM, ci_notify@linaro.org wrote:
Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
We understand that it might be difficult to find the necessary logs or reproduce the issue locally. If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
In gdb_check master-arm after:
| gdb patch https://patchwork.sourceware.org/patch/97698 | Author: Guinevere Larsen <blarsen@redhat.com> | Date: Thu Sep 19 09:42:04 2024 -0300 | | gdb/testsuite: rework bp-cond-failure to not depend on inlining | | The test gdb.base/bp-cond-failure is implicitly expecting that the | function foo will be inlined twice and gdb will be able to find 2 | locations to place a breakpoint. When clang is used, gdb only finds | one location which causes the test to fail. Since the test is not | worried about handling breakpoints on inlined functions, but rather on | ... 11 lines of the commit log omitted. | ... applied on top of baseline commit: | d3acf3d759d Rename tui_suppress_outputFAIL: 1 regressions: 1 improvements
regressions.sum: === gdb tests ===
Running gdb:gdb.base/return.exp ... ERROR: no fileid for 5a8f76db3a07
improvements.sum: === gdb tests ===
Running gdb:gdb.base/return.exp ... ERROR: no fileid for a55c644d3a50
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
The configuration of this build is: CI config tcwg_gdb_check master-arm
-----------------8<--------------------------8<--------------------------8<-------------------------- The information below can be used to reproduce a debug environment:
Current build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-precommit/3013/artifact... Reference build : https://ci.linaro.org/job/tcwg_gdb_check--master-arm-build/1786/artifact/art...
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
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
Guinevere Larsen