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: YA call for snapshot testing

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:

On 22/01/12 05:18, Christopher Faylor wrote:
Thanks for the positive feedback. It looks like if we can fix Yaakov's
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?


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/': 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:
Unsubscribe info:

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