bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #25294] assertion failure on dangling symlink to //


From: Eric Blake
Subject: [bug #25294] assertion failure on dangling symlink to //
Date: Sat, 10 Jan 2009 23:44:15 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Mnenhy/0.7.5.666

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: address@hidden
             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

[Prev in Thread] Current Thread [Next in Thread]