On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote: > This patch fixes the ICE caused by valid_to_unchecked_state, > at analyzer/sm-fd.cc by handling the m_start state in > check_for_dup. > > Tested lightly on x86_64. > > gcc/analyzer/ChangeLog: > PR analyzer/106551 > * sm-fd.cc (check_for_dup): handle the m_start > state when transitioning the state of LHS > of dup, dup2 and dup3 call. > > gcc/testsuite/ChangeLog: > * gcc.dg/analyzer/fd-dup-1.c: New testcases. > > Signed-off-by: Immad Mir <mirim...@outlook.com> > --- > gcc/analyzer/sm-fd.cc | 4 ++-- > gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 28 > +++++++++++++++++++++++- > 2 files changed, 29 insertions(+), 3 deletions(-) > > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc > index 8bb76d72b05..c8b9930a7b6 100644 > --- a/gcc/analyzer/sm-fd.cc > +++ b/gcc/analyzer/sm-fd.cc > @@ -983,7 +983,7 @@ fd_state_machine::check_for_dup (sm_context > *sm_ctxt, const supernode *node, > case DUP_1: > if (lhs) > { > - if (is_constant_fd_p (state_arg_1)) > + if (is_constant_fd_p (state_arg_1) || state_arg_1 == > m_start) > sm_ctxt->set_next_state (stmt, lhs, > m_unchecked_read_write); > else > sm_ctxt->set_next_state (stmt, lhs, > @@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup (sm_context > *sm_ctxt, const supernode *node, > file descriptor i.e the first argument. */ > if (lhs) > { > - if (is_constant_fd_p (state_arg_1)) > + if (is_constant_fd_p (state_arg_1) || state_arg_1 == > m_start) > sm_ctxt->set_next_state (stmt, lhs, > m_unchecked_read_write); > else > sm_ctxt->set_next_state (stmt, lhs, > diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c > b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c > index eba2570568f..ed4d6de57db 100644 > --- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c > +++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c > @@ -220,4 +220,30 @@ test_19 (const char *path, void *buf) > close (fd); > } > > -} > \ No newline at end of file > +} > + > +void > +test_20 () > +{ > + int m; > + int fd = dup (m); /* { dg-warning "'dup' on possibly invalid > file descriptor 'm'" } */ > + close (fd); > +} > + > +void > +test_21 () > +{ > + int m; > + int fd = dup2 (m, 1); /* { dg-warning "'dup2' on possibly > invalid file descriptor 'm'" } */ > + close (fd); > +} > + > +void > +test_22 (int flags) > +{ > + int m; > + int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on possibly > invalid file descriptor 'm'" } */ > + close (fd); > +}
Thanks for the updated patch. The test cases looked suspicious to me - I was wondering why the analyzer doesn't complain about the uninitialized values being passed to the various dup functions as parameters. So your test cases seem to have uncovered a hidden pre-existing bug in the analyzer's uninitialized value detection, which I've filed for myself to deal with as PR analyzer/106573. If you convert the "int m;" locals into an extern global, like in comment #0 of bug 106551, does that still trigger the crash on the unpatched sm-fd.cc? If so, then that's greatly preferable as a regression test, since otherwise I'll have to modify that test case when I fix bug 106573. Dave