* Odd Python errors in the G++ testsuite
@ 2023-10-09 19:12 Maciej W. Rozycki
2023-10-09 23:42 ` Ben Boeckel
2023-10-10 0:09 ` Ben Boeckel
0 siblings, 2 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2023-10-09 19:12 UTC (permalink / raw)
To: gcc
Hi,
I'm seeing these tracebacks for several cases across the G++ testsuite:
Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
rules/0/primary-output is ok: p1689-1.o
rules/0/provides/0/logical-name is ok: foo
rules/0/provides/0/is-interface is ok: True
Traceback (most recent call last):
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in <module>
is_ok = validate_p1689(actual, expect)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in validate_p1689
return compare_json([], actual_json, expect_json)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
is_ok = _compare_object(path, actual, expect)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
sub_error = compare_json(path + [key], actual[key], expect[key])
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in compare_json
is_ok = _compare_array(path, actual, expect)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in _compare_array
sub_error = compare_json(path + [str(idx)], a, e)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
is_ok = _compare_object(path, actual, expect)
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
sub_error = compare_json(path + [key], actual[key], expect[key])
File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in compare_json
actual = set(actual)
TypeError: unhashable type: 'dict'
and also these intermittent failures for other cases:
Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
rules/0/primary-output is ok: p1689-2.o
rules/0/provides/0/logical-name is ok: foo:part1
rules/0/provides/0/is-interface is ok: True
ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
version is ok: 0
revision is ok: 0
FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
This does seem to me like something not working as intended. As a Python
non-expert I have troubles concluding what is going on here and whether
these tracebacks are indeed supposed to be there, or whether it is a sign
of a problem. And these failures I don't even know where they come from.
Does anyone know? Is there a way to run the offending commands by hand?
The relevant invocation lines do not appear in the test log file for one
to copy and paste, which I think is not the right way of doing things in
our environment.
These issues seem independent from the test host environment as I can see
them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine
in `riscv64-linux-gnu' target testing.
Maciej
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Odd Python errors in the G++ testsuite
2023-10-09 19:12 Odd Python errors in the G++ testsuite Maciej W. Rozycki
@ 2023-10-09 23:42 ` Ben Boeckel
2023-10-09 23:46 ` Paul Koning
2024-02-02 10:54 ` Maciej W. Rozycki
2023-10-10 0:09 ` Ben Boeckel
1 sibling, 2 replies; 6+ messages in thread
From: Ben Boeckel @ 2023-10-09 23:42 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gcc
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
What version of Python3 do you have? The test suite might not actually
properly handle not having 3.7 (i.e., skip the tests that require it).
> rules/0/primary-output is ok: p1689-1.o
I wrote these tests.
> rules/0/provides/0/logical-name is ok: foo
> rules/0/provides/0/is-interface is ok: True
> Traceback (most recent call last):
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in <module>
> is_ok = validate_p1689(actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in validate_p1689
> return compare_json([], actual_json, expect_json)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> is_ok = _compare_object(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in compare_json
> is_ok = _compare_array(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in _compare_array
> sub_error = compare_json(path + [str(idx)], a, e)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> is_ok = _compare_object(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in compare_json
> actual = set(actual)
> TypeError: unhashable type: 'dict'
I'm not sure how this ends up with a dictionary in it… Can you
`print(actual)` before this?
> and also these intermittent failures for other cases:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> rules/0/primary-output is ok: p1689-2.o
> rules/0/provides/0/logical-name is ok: foo:part1
> rules/0/provides/0/is-interface is ok: True
> ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> version is ok: 0
> revision is ok: 0
> FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
>
> This does seem to me like something not working as intended. As a Python
> non-expert I have troubles concluding what is going on here and whether
> these tracebacks are indeed supposed to be there, or whether it is a sign
> of a problem. And these failures I don't even know where they come from.
>
> Does anyone know? Is there a way to run the offending commands by hand?
> The relevant invocation lines do not appear in the test log file for one
> to copy and paste, which I think is not the right way of doing things in
> our environment.
>
> These issues seem independent from the test host environment as I can see
> them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine
> in `riscv64-linux-gnu' target testing.
Do they all have pre-3.7 Python3 versions?
--Ben
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Odd Python errors in the G++ testsuite
2023-10-09 23:42 ` Ben Boeckel
@ 2023-10-09 23:46 ` Paul Koning
2023-10-10 0:00 ` Ben Boeckel
2024-02-02 10:54 ` Maciej W. Rozycki
1 sibling, 1 reply; 6+ messages in thread
From: Paul Koning @ 2023-10-09 23:46 UTC (permalink / raw)
To: Ben Boeckel; +Cc: Maciej W. Rozycki, gcc
> On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
>> I'm seeing these tracebacks for several cases across the G++ testsuite:
>>
>> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
>> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
>
> What version of Python3 do you have? The test suite might not actually
> properly handle not having 3.7 (i.e., skip the tests that require it).
But the rule that you can't put a dict in a set is as old as set support (2.x for some small x).
paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Odd Python errors in the G++ testsuite
2023-10-09 23:46 ` Paul Koning
@ 2023-10-10 0:00 ` Ben Boeckel
0 siblings, 0 replies; 6+ messages in thread
From: Ben Boeckel @ 2023-10-10 0:00 UTC (permalink / raw)
To: Paul Koning; +Cc: Maciej W. Rozycki, gcc
On Mon, Oct 09, 2023 at 19:46:37 -0400, Paul Koning wrote:
>
>
> > On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> >> I'm seeing these tracebacks for several cases across the G++ testsuite:
> >>
> >> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> >> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> >
> > What version of Python3 do you have? The test suite might not actually
> > properly handle not having 3.7 (i.e., skip the tests that require it).
>
> But the rule that you can't put a dict in a set is as old as set support (2.x for some small x).
Yes. I just wonder how a dictionary got in there in the first place. I'm
not sure if some *other* 3.7-related change makes that work.
--Ben
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Odd Python errors in the G++ testsuite
2023-10-09 19:12 Odd Python errors in the G++ testsuite Maciej W. Rozycki
2023-10-09 23:42 ` Ben Boeckel
@ 2023-10-10 0:09 ` Ben Boeckel
1 sibling, 0 replies; 6+ messages in thread
From: Ben Boeckel @ 2023-10-10 0:09 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gcc
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> Hi,
>
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> rules/0/primary-output is ok: p1689-1.o
> rules/0/provides/0/logical-name is ok: foo
> rules/0/provides/0/is-interface is ok: True
> Traceback (most recent call last):
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in <module>
> is_ok = validate_p1689(actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in validate_p1689
> return compare_json([], actual_json, expect_json)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> is_ok = _compare_object(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in compare_json
> is_ok = _compare_array(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in _compare_array
> sub_error = compare_json(path + [str(idx)], a, e)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> is_ok = _compare_object(path, actual, expect)
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
> File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in compare_json
> actual = set(actual)
> TypeError: unhashable type: 'dict'
So looking at the source…the 3.6 check is not from me. Not sure what's
up there; it's probably not immediately related to the backtrace.
But this backtrace means that we have a list of objects that do not
expect a given ordering that is of JSON objects. I'm not sure why this
never showed up before as all of the existing uses of it are indeed of
objects. Can you try removing `"__P1689_unordered__"` from the
`p1689-1.exp.ddi` file's `requires` array? The
`p1689-file-default.exp.ddi` and `p1689-target-default.exp.ddi` files
need the same treatment.
--Ben
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Odd Python errors in the G++ testsuite
2023-10-09 23:42 ` Ben Boeckel
2023-10-09 23:46 ` Paul Koning
@ 2024-02-02 10:54 ` Maciej W. Rozycki
1 sibling, 0 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2024-02-02 10:54 UTC (permalink / raw)
To: Ben Boeckel; +Cc: gcc
Hi Ben,
This has fallen between the cracks.
On Mon, 9 Oct 2023, Ben Boeckel wrote:
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> > I'm seeing these tracebacks for several cases across the G++ testsuite:
> >
> > Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> > spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
>
> What version of Python3 do you have? The test suite might not actually
> properly handle not having 3.7 (i.e., skip the tests that require it).
One system has:
$ python3 --version
Python 3.10.12
$
and the other has:
$ python3 --version
Python 3.9.2
$
-- are these correct versions?
> > rules/0/primary-output is ok: p1689-1.o
>
> I wrote these tests.
Ack.
> > rules/0/provides/0/logical-name is ok: foo
> > rules/0/provides/0/is-interface is ok: True
> > Traceback (most recent call last):
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in <module>
> > is_ok = validate_p1689(actual, expect)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in validate_p1689
> > return compare_json([], actual_json, expect_json)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> > is_ok = _compare_object(path, actual, expect)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> > sub_error = compare_json(path + [key], actual[key], expect[key])
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in compare_json
> > is_ok = _compare_array(path, actual, expect)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in _compare_array
> > sub_error = compare_json(path + [str(idx)], a, e)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in compare_json
> > is_ok = _compare_object(path, actual, expect)
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in _compare_object
> > sub_error = compare_json(path + [key], actual[key], expect[key])
> > File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in compare_json
> > actual = set(actual)
> > TypeError: unhashable type: 'dict'
>
> I'm not sure how this ends up with a dictionary in it… Can you
> `print(actual)` before this?
I'll see if I can still reproduce the issue and add some diagnostics if
so.
> > and also these intermittent failures for other cases:
> >
> > Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" (timeout = 300)
> > spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> > rules/0/primary-output is ok: p1689-2.o
> > rules/0/provides/0/logical-name is ok: foo:part1
> > rules/0/provides/0/is-interface is ok: True
> > ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> > version is ok: 0
> > revision is ok: 0
> > FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> >
> > This does seem to me like something not working as intended. As a Python
> > non-expert I have troubles concluding what is going on here and whether
> > these tracebacks are indeed supposed to be there, or whether it is a sign
> > of a problem. And these failures I don't even know where they come from.
> >
> > Does anyone know? Is there a way to run the offending commands by hand?
> > The relevant invocation lines do not appear in the test log file for one
> > to copy and paste, which I think is not the right way of doing things in
> > our environment.
> >
> > These issues seem independent from the test host environment as I can see
> > them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine
> > in `riscv64-linux-gnu' target testing.
>
> Do they all have pre-3.7 Python3 versions?
None of them, as noted above.
Maciej
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-02-02 10:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-09 19:12 Odd Python errors in the G++ testsuite Maciej W. Rozycki
2023-10-09 23:42 ` Ben Boeckel
2023-10-09 23:46 ` Paul Koning
2023-10-10 0:00 ` Ben Boeckel
2024-02-02 10:54 ` Maciej W. Rozycki
2023-10-10 0:09 ` Ben Boeckel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).