On Sun, 2023-03-26 at 18:03 +0200, Shengyu Huang wrote:
> Hi Dave,
>
> (I forgot to cc the list in the last email and it was too late to
> unsend. Sorry for sending you the same email again.)
>
> > On 20 Mar 2023, at 23:50, David Malcolm
> > <dmalc...@redhat.com <mailto:dmalc...@redhat.com>> wrote:
> >
> > I think if you try the patch to sm.cc <http://sm.cc/> above, then
> > you'll see
> > various existing DejaGnu tests below gcc.dg/analyzer will fail with
> > state explosions.
>
> After patching on the latest trunk, the DejaGnu tests report two
> cases with state explosion:
>
> pr93032-mztools-{signed, unsigned}-char.c
>
> I didn’t see any cases with ICE though.
>
> In addition, although I did see “warning: terminating analysis for
> this program point…” in the test log, nothing was reported when I ran
> the individual test (with or without gdb)…Did I miss anything?
The warning is coming from -Wanalyzer-too-complex. This is disabled by
default with -fanalyzer, so you won't see it if you try to compile the
.c file "by hand", but the testsuite enables it by default (in
analyzer.exp).
>
> Just by looking at these test files, it seems that it may have to do
> with how the analyzer does path selection, because there are many
> nested conditionals in these two files. As I mentioned in the
> proposal, it would be curious if this state explosion only happens
> for taint analysis, because I don’t think there is anything special
> about taint analysis that would cause state explosion (unless there
> is some buggy implementation?).
I has looked into compiling those files with the patch some time ago;
looking at my notes, one issue was with this on-stack buffer:
char extra[1024];
declared outside the loop. Inside the loop, it gets modified in
various ways:
extra[0] = '\0';
and
if (fread(extra, 1, extsize, fpZip) == extsize) {
where the latter means "extra" becomes tainted.
However "extra" is barely used, and is effectively reset each time
through the loop - but the analyzer doesn't figure that out. So the
loop analysis explodes, as it tries to keep track of the possibility
that "extra" is still tainted from previous iteration(s), despite the
fact that it's going to be clobbered before it ever gets used.
So one fix might be to extend the state-purging code so that it somehow
"sees" that "extra" gets clobbered before it gets used, and thus we can
purge the tainted state from it.
Hope that makes sense
Dave
>
> I will look at your latest patch. It seems that there are many useful
> tips that can help me further investigate the internals of analyzer.
> Thanks a lot!
>
> Best,
> Shengyu
