This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]