| commit | 13ddcf0a7a52ce17c836edbe6fc161a40269ce13 | |
| author | Alex Bennée <alex.bennee@linaro.org> | |
| Tue, 5 Mar 2024 12:09:37 +0000 (5 12:09 +0000) | ||
| committer | Alex Bennée <alex.bennee@linaro.org> | |
| Wed, 6 Mar 2024 12:35:09 +0000 (6 12:35 +0000) | ||
| tree | b47f1e43e807add18e4e56f95679ae7be9ed472d | treesnapshot (tar.gz zip) |
| parent | db596ae19040574e41d086e78469014191d7d7fc | commitdiff |
tests: bump QOS_PATH_MAX_ELEMENT_SIZE again
We "fixed" a bug with LTO builds with 100c459f194 (tests/qtest: bump
up QOS_PATH_MAX_ELEMENT_SIZE) but it seems it has triggered again.
The array is sized according to the maximum anticipated length of a
path on the graph. However, the worst case for a depth-first search is
to push all nodes on the graph. So it's not really LTO, it depends on
the ordering of the constructors.
Lets be more assertive raising QOS_PATH_MAX_ELEMENT_SIZE to make it go
away again.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1186 (again)
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240305121005.3528075-2-alex.bennee@linaro.org>
We "fixed" a bug with LTO builds with 100c459f194 (tests/qtest: bump
up QOS_PATH_MAX_ELEMENT_SIZE) but it seems it has triggered again.
The array is sized according to the maximum anticipated length of a
path on the graph. However, the worst case for a depth-first search is
to push all nodes on the graph. So it's not really LTO, it depends on
the ordering of the constructors.
Lets be more assertive raising QOS_PATH_MAX_ELEMENT_SIZE to make it go
away again.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1186 (again)
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240305121005.3528075-2-alex.bennee@linaro.org>
| tests/qtest/libqos/qgraph.h | diffblobblamehistory |