Mail Archives: cygwin/2009/01/08/11:36:45
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
|
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/
- Raw text -