> 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?
Yes, it does, since m would be in "m_start" state. I'm sending an updated patch. Thanks Immad. On Wed, Aug 10, 2022 at 1:32 AM David Malcolm <dmalc...@redhat.com> wrote: > 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 > > > >