URL:
  <http://savannah.gnu.org/bugs/?25294>

                 Summary: assertion failure on dangling symlink to //
                 Project: findutils
            Submitted by: ericb
            Submitted on: Sat 10 Jan 2009 04:44:14 PM MST
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Eric Blake
        Originator Email: [email protected]
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.5.3
           Fixed Release: None

    _______________________________________________________

Details:

On systems where d_type is valid, find is triggering an assertion (I'm not
sure if this assertion also requires that // be distinct from /, in which case
the assertion may be specific to cygwin 1.7, since earlier cygwin lack d_type
and other systems don't have distinct //):

$ mkdir example
$ ln -s /nowhere example/n
$ find -L example
example
example/n

but the following asserts:

$ rm example/n
$ ln -s //nowhere example/n
$ find -L example
example
assertion "state.type != 0" failed: file
"/usr/src/findutils-4.5.3-1/src/findutils-4.5.3/find/ftsfind.c", line 475,
function: consider_visiting
Aborted (core dumped)


Corinna Vinschen provided this analysis:

The assertion is basically

  if (ent->fts_info == FTS_NSOK || ent->fts_info == FTS_NS)
    assert (state.type != 0);

state.type is set in the calling function find() like this:

  while ( (ent=fts_read(p)) != NULL )
    {
      state.have_type = !!ent->fts_statp->st_mode;
      state.type = state.have_type ? ent->fts_statp->st_mode : 0;
    }

which is a bug, AFAICS.  The reason is that per the fts_read man page
the value of ent->fts_statp is undefined if ent->fts_info is FTS_NSOK
or FTS_NS.  So the values of state.have_type and consequentially
state.type are undefined as well and the above assertion makes no sense.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25294>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




Reply via email to