X-Recipient: archive-cygwin@delorie.com
X-Spam-Check-By: sourceware.org
Date: Tue, 12 Jan 2010 17:48:34 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Tried out cygwin-inst-20100111.tar.bz2
Message-ID: <20100112164834.GV14511@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <COL102-W462D97538DD6B7BAA121D5B56C0@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <COL102-W462D97538DD6B7BAA121D5B56C0@phx.gbl>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com

On Jan 11 22:39, Karl M wrote:
> 
> 
> Hi All...
>  
> I just tried out the latest snapshot and had two problems on a Vista Business SP2 machine.
>  
> The first problem was that in bash shell launched from the cygwin.bat file in a console
> window, the backspace did nothing.
>  
> I also received the following error from find:
>  
> $ find / -name '*code.exe'
> /lib/code.exe
> /lib/frcode.exe
> find: `/tmp/ssh-OksMRN4552': Permission denied
> /usr/lib/code.exe
> /usr/lib/frcode.exe
> assertion "ent->fts_info == FTS_NSOK || state.type != 0" failed: file "/usr/src/findutils-4.5.5-1/src/findutils-4.5.5/find/ftsfind.c", line 477, function: consider_visiting
>       3 [main] find 2160 sig_send: wait for sig_complete event failed, signal 6, rc 258, Win32 error 0

I can reproduce find(1) failing, but it's not clear to me where and why
this happens.  Apparently there's a point where internally allocated
space gets overwritten while recursively calling readdir.  Due to the
huge number of files it's not easy to catch the place where this happens.

OTOH this does not occur when recursively calling readdir using ls(1)
which allows the assumption that it's find, not Cygwin, which overwrites
the memory.

Where's the difference between find and ls when recursing through
directories?  Eric, do you see a chance to find time to debug this?


Thanks,
Corinna

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

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

