Oh, wait, this is not a path! This is the stack for a graph visit, and the
limit is not the maximum length of the path, but rather the number of nodes
in the graph.

In other words, QOS_PATH_MAX_ELEMENT_SIZE is being overloaded and using it
in qos_node_stack is wrong. The solution is to use a linked list there, for
now the patch is okay.

Paolo

Il mer 28 set 2022, 10:48 Alex Bennée <alex.ben...@linaro.org> ha scritto:

>
> Paolo Bonzini <pbonz...@redhat.com> writes:
>
> > What is an example of one such huge path? This would mean that LTO is
> changing the set of tests that are run, which is
> > unexpected.
>
> It does look like the LTO build runs more tests although its hard to
> diff as the order if different:
>
> ➜  grep "list" without-lto | wc -l
> 201
> 🕙09:45:35 alex@zen:qemu.git/builds/arm.all  on  gitdm/next [$!?⇡]
> ➜  grep "list" ../debug/with-lto | wc -l
> 195
>
> Logs attached:
>
>
> >
> > Paolo
> >
> > Il mar 27 set 2022, 23:35 Alex Bennée <alex.ben...@linaro.org> ha
> scritto:
> >
> >  It seems the depth of path we need to support can vary depending on
> >  the order of the init constructors getting called. It seems
> >  --enable-lto shuffles things around just enough to push you over the
> >  limit.
> >
> >  Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
> >  Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186
> >  ---
> >   tests/qtest/libqos/qgraph.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >  diff --git a/tests/qtest/libqos/qgraph.h b/tests/qtest/libqos/qgraph.h
> >  index 6e94824d09..5c0046e989 100644
> >  --- a/tests/qtest/libqos/qgraph.h
> >  +++ b/tests/qtest/libqos/qgraph.h
> >  @@ -24,7 +24,7 @@
> >   #include "libqos-malloc.h"
> >
> >   /* maximum path length */
> >  -#define QOS_PATH_MAX_ELEMENT_SIZE 50
> >  +#define QOS_PATH_MAX_ELEMENT_SIZE 64
> >
> >   typedef struct QOSGraphObject QOSGraphObject;
> >   typedef struct QOSGraphNode QOSGraphNode;
> >  --
> >  2.34.1
>
>
> --
> Alex Bennée
>

Reply via email to