From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by sourceware.org (Postfix) with ESMTPS id EA8A23851C09 for ; Sun, 6 Sep 2020 23:19:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EA8A23851C09 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cs.umass.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=moss@cs.umass.edu Received: from [192.168.0.30] (c-24-62-203-86.hsd1.ma.comcast.net [24.62.203.86]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id 909F04023BA6; Sun, 6 Sep 2020 19:19:25 -0400 (EDT) Reply-To: moss@cs.umass.edu Subject: Re: ag 2 <(echo 2) gets assertion "p >= path" failed: .. /cygwin-3.1.7 ... /cygwin/path.cc", line 3065, function: int symlink_info::check To: David Dyck Cc: cygwin@cygwin.com References: From: Eliot Moss Message-ID: Date: Sun, 6 Sep 2020 19:19:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2020 23:19:27 -0000 On 9/6/2020 6:15 PM, David Dyck wrote: > > > On Sun, Sep 6, 2020 at 12:07 PM Eliot Moss > wrote: > > > > On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote: > > > This command triggers an assertion failure > > >    "ag" is from the_silver_searcher > > > > > > $ ag 2 <(echo 2) > > > assertion "p >= path" failed: file > > > > "/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc", > > > line 3065, function: int symlink_info::check(char*, const > > > suffix_info*, fs_info&, path_conv_handle&) > > > > > I just tried this: > > > >    grep 2 <(echo 2) > > > > on cygwin 3.1.7 and it worked fine.  I am not familiar with Silver Searcher, but it would > > seem that the problem is more idiosyncratic to that program than to Cygwin more generally. > > I am _not_ saying the problem is not in Cygwin - only that ag must be doing something > > somewhat different from what grep does with <( ) command input.  Perhaps ag is testing > > what sort of "thing" (device, etc.) the input file is, while grep does not - something > > like that might give different behavior. > > > > Now I have CYGWIN=winsymlinks:native, which may (almost certainly does) affect what > > path.cc is doing (the error message is concerned about symlinks; presumably Cygwin > > is trying to check whether /dev/fd/63 is a symlink. > > > > Well, those are the clues I can offer :-) ...   EM > > Thanks,  I tried >   export CYGWIN=winsymlinks:native > and it still asserted > > I think the "ag" uses mmap and pthreads - at least that is what the manual page indicated - >  though even when I passed --nommap I still got the assertion, > > From man ag: > > How is it so fast? > * Searching for literals (no regex) uses Boyer-Moore-Horspool strstr. > * Files are mmap()ed instead of read into a buffer. > * If you're building with PCRE 8.21 or greater, regex searches use the JIT compiler. > * Ag calls pcre_study() before executing the regex on a jillion files. > * Instead of calling fnmatch() on every pattern in your ignore files, non-regex patterns are > loaded into an array and binary searched. > * Ag uses Pthreads to take advantage of multiple CPU cores and search files in parallel. Yes, mmap would fail on a device file like this, but the failure is when trying to open a .ignore file under the device file (which won't exist), as I recall. As others indicated, there is a problem in cygwin. It might have to do with flavors of symlink, but maybe not. Anyway, seems folks are onto it. Best wishes - EM