X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_54,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)
Date: Thu, 8 Jan 2009 16:36:17 +0000 (UTC)
Lines: 47
Message-ID:  <loom.20090108T162816-939@post.gmane.org>
References:  <495A4B87 DOT 3080009 AT partners DOT org> <20081230170638 DOT GB5230 AT ednor DOT casa DOT cgf DOT cx> <20081230174104 DOT GD5230 AT ednor DOT casa DOT cgf DOT cx> <20081230175246 DOT GE5230 AT ednor DOT casa DOT cgf DOT cx> <20081230190603 DOT GA13443 AT ednor DOT casa DOT cgf DOT cx> <20090108153111 DOT GA18089 AT calimero DOT vinschen DOT de>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> > >Hmm.  After removing the /dev/fd directory that I had created years
> > >ago, find now just SEGVs.  And, it seems to be dying in find itself
> > >if the stack dump is any indication.
> > >
> > >Eric, is there any way that you could confirm or deny this?  I would
> > >rather not build a debugging version of find if I don't have to.

I still haven't had time to take a closer look into this.  But it's on my list.

> 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.

find uses gnulib's implementation of fts, not cygwin's.  Gnulib's variant has 
the added advantage of using openat() and friends, for linear instead of 
quadratic recursion speed on deep hierarchies (provided, of course, that you 
have an OS that supports linear speeds, and not all versions of Windows 
qualify), as well as thread-safety in multi-threaded apps (BSD and glibc fts 
are not thread-safe, since they can call chdir).  Therefore, this might not 
actually be a bug in find, because of the difference in fts implementations 
(the gnulib folks have been debating about renaming their implementation gfts, 
to document that it is a better interface than traditional fts).

I also know about a recent upstream patch that fixed the use of an 
uninitialized variable related to st_mode, that was not part of findutils 
4.5.3.  I'm not sure if it is related to this particular issue, but it is a 
possibility.

-- 
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/