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 227D03851C35 for ; Sun, 6 Sep 2020 19:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 227D03851C35 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 9B672401EB80; Sun, 6 Sep 2020 15:07:35 -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 , cygwin@cygwin.com References: From: Eliot Moss Message-ID: Date: Sun, 6 Sep 2020 15:07:35 -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: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, 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 19:07:37 -0000 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&) > Aborted (core dumped) > > 3473k 2020/08/22 C:\cygwin64\bin\cygwin1.dll > Cygwin DLL version info: > DLL version: 3.1.7 > bash 4.4.12-3 OK > the_silver_searcher 2.2.0-1 OK > > Wrapping in "bash -c" gives identical results ( see above) > $ /usr/bin/bash -c '/usr/bin/ag 2 <(echo 2)' > > Turning on some "ag" debugging reveals worker threads and the > "special" /dev/fd/63 file handle creation ( used with bash "Process > Substitution" ) > > $ /usr/bin/bash -c '/usr/bin/ag -D 2 <(echo 2)' > .... > DEBUG: Query is 2 > DEBUG: PCRE Version: 8.44 2020-02-12 > DEBUG: Using 7 workers > DEBUG: Thread 0 set to CPU 0 > DEBUG: Thread 1 set to CPU 1 > DEBUG: Worker 1 started > DEBUG: Worker 0 started > ... > DEBUG: searching path /dev/fd/63 for 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&) > Aborted (core dumped) > > > I expected behaviour like ack > > $ ack 2 <(echo 2) > 2 > > Noticed that input from pipe works > > $ echo 2 | ag 2 > 2 > > I've reported this on github as an "ag" bug, but I think it is a bug in cygwin > https://github.com/ggreer/the_silver_searcher/issues/1408 > > I would appreciate hearing if someone else can reproduce this issue in > 3.1.7 or later dll > ( 3.1.6 seems to hang ) > > Attached cygcheck.out > UserName and HostName substituted into cygcheck.out > one environment variable deleted 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