Re: YA call for snapshot testing

[marco atzeri <marco dot atzeri at gmail dot com>]

On 1/22/2012 6:53 AM, Christopher Faylor wrote:
> On Sun, Jan 22, 2012 at 12:47:19AM -0500, Christopher Faylor wrote:
> > On Sun, Jan 22, 2012 at 01:07:45PM +1100, Shaddy Baddah wrote:
> > > Hi,
> > >
> > >
> > > On 22/01/12 05:18, Christopher Faylor wrote:
> > > > Thanks for the positive feedback. It looks like if we can fix Yaakov's
> > > > problem
> > > > we may be ready to ship.
> > >
> > > I have one more problem to report. I tracked this problem as being
> > > introduced in the 2011-12-17 00:14:25 UTC snapshot, including the
> > > latest one, 2012-01-11 22:44:48 UTC:

Cgf
I saw the problem in erratic way also before running updatedb.
But it is very evanescent and usually linked on how find is called.

> > Sorry but you'll really need to provide more details about what your
> > disk looks like so that we can attempt to duplicate the problem.
> >
> > Also, the stack trace that you provided doesn't look like it came from
> > the 2012-01-11 snapshot.  I can't tell for sure since you didn't provide
> > cygcheck outpput.
>
> Also did this crash happen instantaneously or did it take a while?
>
> cgf

on
CYGWIN_NT-6.1-WOW64 1.7.10s(0.259/5/3) 20120111 22:39:26

I have 2 NTFS disks and cygwin is on e:\cygwin

Today, this worked flawless
$ updatedb --localpaths='/' --prunepaths='/proc /cygdrive'

while this failed
$ updatedb --localpaths='/' --prunepaths='/proc /cygdrive/e/cygwin

or with something like
--------------------------------------------------------------------------
/usr/bin/find: File system loop detected; `/cygdrive/e/cygwin' is part 
of the same file system loop as `/'.
/usr/bin/find: 
`/pub/devel/hdf5/hdf5-1.8.8-1/src/hdf5-1.8.8/tools/h5ja/testh5jam.sh.in': Bad 
address
/usr/bin/find: `/pub/devel/hdf5/hdf5-1.8.8-1/src/hdf5-1.8.8/tool/h5ls': 
Bad address
----------------------------------------------------------------------

or with
----------------------------------------------------------------------
/usr/bin/find: File system loop detected; `/cygdrive/e/cygwin' is part 
of the same file system loop as `/'.
      0 [main] find 6920 E:\cygwin\bin\find.exe: *** fatal error - 
cwcsdup would have returned NULL
Stack trace:
Frame     Function  Args
0028B478  6102F93B  (0028B478, 00000000, 00000000, 61003067)
0028B768  6102F93B  (6119CD20, 00008000, 00000000, 6119EB0F)
0028C798  61005E5C  (611CD458, 0028C7C4, 6EF9FE64, 00000000)
0028C7B8  61005E98  (611CD458, 00000000, FFFFFFFF, 6EF9FE64)
End of stack trace
/usr/bin/updatedb: line 368:  6920 Hangup                  $find 
$SEARCHPATHS $FINDOPTIONS \( $prunefs_exp -type d -regex "$PRUNEREGEX" 
\) -prune -o $print_option
------------------------------------------------------------------------

The first case is the one I saw more times in the past, and it was 
seldom in the same portion of the file tree, and I had no problem
accessing the "bad address" files. I don't think it
is related to disks defects, but more on some cache or memory
issue when find (or cygwin) is managing it own data.

cygcheck output attached.


Regards
Marco

PS: I am not in next week and I can follow the discussion

Attachment: cygcheck.out
Description: Text document

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