[Top][All Lists]
[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/