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

2009-01-10 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Corinna Vinschen on 1/9/2009 4:45 AM:
 That's what happens in gnulib's fts in case of returning FTS_NS:
 
   memset(sbp, 0, sizeof(struct stat));
   return (FTS_NS);
 
 So st_mode is 0 here, too and the same problem occurs.

Here's what I'm reporting upstream:

when d_type directory traversal is enabled, the following sequence is okay:

$ 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)

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpMa0ACgkQ84KuGfSFAYAffgCgy5y0VEA/ACr3v0AX9li0/iYy
Bg8AoIrgALf8b75OZdqDIDfcC2+H/PI/
=DvwO
-END PGP SIGNATURE-

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

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

2009-01-10 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Corinna Vinschen on 1/9/2009 4:45 AM:
 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 bug is not here, since gnulib's fts is smart enough to populate
ent-fts_statp-st_mode (but nothing else) using d_type information
learned during readdir when FTS_NOSTAT is requested, thus deferring (or
avoiding) the need for stat.  In other words, state.type can be valid even
when a FTS_NSOK or FTS_NS.

But the later assertion is a bug, since it is possible to have neither the
stat (since find used FTS_NOSTAT) nor a type (when d_type was DT_UNKNOWN),
in which case a stat must be performed.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpUBcACgkQ84KuGfSFAYCwvwCfZRvs0DRCoBL+YRsqgs5HbF6y
kXcAoJjbwRzxqCHcxHLady4XB/MNLUFX
=K7yf
-END PGP SIGNATURE-

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

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

2009-01-09 Thread Corinna Vinschen 
On Jan  8 16:36, Eric Blake wrote:
 Corinna Vinschen corinna-cygwin at cygwin.com writes:
  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.
 [...]
 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.

That's what happens in gnulib's fts in case of returning FTS_NS:

  memset(sbp, 0, sizeof(struct stat));
  return (FTS_NS);

So st_mode is 0 here, too and the same problem occurs.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

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

2009-01-08 Thread Corinna Vinschen 
On Dec 30 14:06, Christopher Faylor wrote:
 On Tue, Dec 30, 2008 at 12:52:46PM -0500, Christopher Faylor wrote:
 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.
 
 It was stupid of me to assume that this was just a generic find problem.
 If I'd actually checked the error log I would have seen this:
 
 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
 
 This is apparently caused by a symlink that looks like this:
 
 lrwxrwxrwx  1 cgf None   6 Jul  9  2005 n - //none
 
 I don't remember creating that symlink.  Apparently I was checking on
 creating symlinks to nonexistent domains back in 2005.
 
 I don't know if this is a find bug or a cygwin bug.  I could see it
 being either or both.

It looks like a find bug to me.

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.

Additionally, consider that the BSD variant of fts_read as used by Cygwin
memset's fts_statp to 0 in the FTS_NS case.  Consequentially:

  state.have_type = !!ent-fts_statp-st_mode
  
  == state.have_type = 0
  == state.type = 0
  == assert (state.type != 0) FAILs


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

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

2009-01-08 Thread Eric Blake 
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/

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

2008-12-31 Thread Gregory Sharp 
 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
 
 This is apparently caused by a symlink that looks like this:
 
 lrwxrwxrwx  1 cgf None   6 Jul  9  2005 n - //none

I confirm the assert in find.  Testing cygwin 1.7 on 
Windows Vista Business SP1 yields crash (not reboot) 
with identical assertion failure.

Fault trigger, however, might be different.  Your trigger 
was on invalid symlink.  My failure on Vista+UDFS occurs 
when find encounters a filename not consistent with current 
locale.  I can't find any pattern to the trigger for 
reboot on Win2k.

Details from tests on Vista are below (song #5 has an 
accent over the i).  Note also the output from ls.
Why are permissions, owner, etc. messed up?

Cygcheck for Vista PC attached.

Thanks for your help.  Please let me know if there is 
anything else I can test.

Greg

-

g...@slumber /cygdrive/e/Enya
$ echo $CYGWIN

g...@slumber /cygdrive/e/Enya
$ echo $LANG

g...@slumber /cygdrive/e/Enya
$ echo $LC_CTYPE

g...@slumber /cygdrive/e/Enya
$ find . -type f -exec cksum {} \;
345961327 13604075 ./A Day Without Rain/01 - Enya - A Day
Without Rain.flac
3680852238 24151922 ./A Day Without Rain/02 - Enya - Wild
Child.flac
3662859760 23902845 ./A Day Without Rain/03 - Enya - Only
Time.flac
1323646772 14051921 ./A Day Without Rain/04 - Enya - Tempus
Vernum.flac
cksum: ./A Day Without Rain/05 - Enya - Deora Ar Mo Chroi.flac:
No such file or
directory
2901799000 25825773 ./A Day Without Rain/06 - Enya - Flora's
Secret.flac
335980607 12891442 ./A Day Without Rain/07 - Enya - Fallen
Embers.flac
1477256642 8797182 ./A Day Without Rain/08 - Enya - Silver
Inches.flac
4027000500 18176956 ./A Day Without Rain/09 - Enya -
Pilgrim.flac
1861032574 24277084 ./A Day Without Rain/10 - Enya - One by
One.flac
40677686 22696897 ./A Day Without Rain/11 - Enya - Lazy
Days.flac

g...@slumber /cygdrive/e/Enya
$ find -L . -type f -exec cksum {} \;
345961327 13604075 ./A Day Without Rain/01 - Enya - A Day
Without Rain.flac
3680852238 24151922 ./A Day Without Rain/02 - Enya - Wild
Child.flac
3662859760 23902845 ./A Day Without Rain/03 - Enya - Only
Time.flac
1323646772 14051921 ./A Day Without Rain/04 - Enya - Tempus
Vernum.flac
assertion state.type != 0 failed: file
/usr/src/findutils-4.5.3-1/src/finduti
ls-4.5.3/find/ftsfind.c, line 475, function: consider_visiting
Stack trace:
Frame Function  Args
0022C8D8  76EEC1B2  (0218, EA60, 00A4, 0022C9CC)
0022C9E8  610B5E03  (, 76EEC274, 775A7F54, )
0022CAC8  610B29A7  (, , , )
0022CB18  610B2DBB  (0A30, 0022CB40, 0022CB54, 0022CB54)
0022CBD8  610B2EE1  (0A30, 0006, 0022CC08, 610B2F85)
0022CBE8  610B2F1C  (0006, 0022CE88, 0022CC08, 27790D43)
0022CC08  610B2F85  (6114C054, 0042B2AF, 0042B04C, 01DB)
0022CC38  6100109B  (0042B04C, 01DB, 0042B3B2, 0042B2AF)
0022CD08  610B01E8  (61282C0C, 0001, 0002, 0009)
0022CD48  00401E4A  (0009, 007F, 0022CD88, 61006EEA)
0022CD88  61006EEA  (, 0022CDC0, 610067E0, 7FFDA000)
End of stack trace
Aborted (core dumped)

g...@slumber /cygdrive/e/Enya
$ ls -l A\ Day\ Without\ Rain/
ls: cannot access A Day Without Rain/05 - Enya - Deora Ar Mo
Chroi.flac: No such file or directory
total 183972
-r--r--r-- 1 gcs6 None 13604075 Dec 26 19:30 01 - Enya - A Day
Without Rain.flac
-r--r--r-- 1 gcs6 None 24151922 Dec 26 19:30 02 - Enya - Wild
Child.flac
-r--r--r-- 1 gcs6 None 23902845 Dec 26 19:30 03 - Enya - Only
Time.flac
-r--r--r-- 1 gcs6 None 14051921 Dec 26 19:30 04 - Enya - Tempus
Vernum.flac
-? ? ??   ?? 05 - Enya - Deora
Ar Mo Chroi.flac
-r--r--r-- 1 gcs6 None 25825773 Dec 26 19:30 06 - Enya - Flora's
Secret.flac
-r--r--r-- 1 gcs6 None 12891442 Dec 26 19:30 07 - Enya - Fallen
Embers.flac
-r--r--r-- 1 gcs6 None  8797182 Dec 26 19:30 08 - Enya - Silver
Inches.flac
-r--r--r-- 1 gcs6 None 18176956 Dec 26 19:30 09 - Enya -
Pilgrim.flac
-r--r--r-- 1 gcs6 None 24277084 Dec 26 19:30 10 - Enya - One by
One.flac
-r--r--r-- 1 gcs6 None 22696897 Dec 26 19:30 11 - Enya - Lazy
Days.flac



Greg Sharp
gregsh...@geocities.com


  

cygcheck.out
Description: 3924260979-cygcheck.out
--
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/