GNU bug report logs - #32943
grep pattern < fifo fails on Cygwin (and MinGW), but not on Linux

Previous Next

Package: grep;

Reported by: Houder <houder <at> xs4all.nl>

Date: Fri, 5 Oct 2018 10:15:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 32943 <at> debbugs.gnu.org (full text, mbox):

From: Houder <houder <at> xs4all.nl>
To: 32943 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#32943: grep pattern < fifo fails on Cygwin (and MinGW), but
 not on Linux
Date: Sat, 06 Oct 2018 23:03:04 +0200
On 2018-10-06 22:12, Paul Eggert wrote:
> Houder wrote:
>> I applied strace to "grep . < fifo", and as far as I can tell "an 
>> lseek
>> is applied to the fifo", which obviously fails.
>> 
>> The "lseek" occurs on Cygwin (and MinGW?), but not on Linux
> 
> That's expected, as the code needs to run lseek in some places on
> Cygwin where it's not needed on GNU/Linux.
> 
> My guess is that you've got an old version of grep on Cygwin, and need
> to upgrade to the current version. If you still have problems with the
> latest version, please investigate via GDB and/or other means exactly
> why grep is failing for you. The strace output isn't enough,
> unfortunately.

Hi Paul,

Thanks for the reply! (I know now that "the list" is aware my post :-)

(and yes, in the mean time I have found plenty of URLs pointing to the
 project and the bug-tracker)

My reply is to the list, CC to you. (or should I only reply to the 
list?)

Old version? The version used by Cygwin is based on 3.0. As far as I can
tell, the most recent tarball is 3.1 ?????

I did investigate using gdb and had a hard time getting a useful result
because of the indirection (grep . < fifo).

After searching the internet, I proceeded as follows:

@@ gdb /usr/bin/grep

This also loads the symbol table on Cygwin.

(gdb) set args .
(gdb) br main
(gdb) run

GDB stops at main()

(gdb) p dup2(open("fifo", 0), 0)

Next I execute "echo aaa > fifo" from another terminal; this makes GDB
return to the prompt (the prompt did not return after the above dup2()).

Subsequently I put a breakpoint on suppressible_error().

When the excution hits the breakpoint, I got this stack trace:

(gdb) bt
#0  suppressible_error (errnum=22) at 
/usr/src/debug/grep-3.0-2/src/grep.c:595
#1  0x0000000100403f05 in grep (ineof=<synthetic pointer>, 
st=0xffffc890, fd=0) at /usr/src/debug/grep-3.0-2/src/grep.c:1480
#2  grepdesc (desc=desc <at> entry=0, command_line=command_line <at> entry=true) 
at /usr/src/debug/grep-3.0-2/src/grep.c:1875
#3  0x0000000100428f74 in grep_command_line_arg (arg=<optimized out>) at 
/usr/src/debug/grep-3.0-2/src/grep.c:1915
#4  main (argc=<optimized out>, argv=<optimized out>) at 
/usr/src/debug/grep-3.0-2/src/grep.c:294

This "translates" to the following callflow:

main
  grep_command_line_arg
    grepdesc
      grep
        reset # appears to return true ...
        fillbuf # (1st call in grep() ) appears to return false
          suppressible_error

However I am not sure of this result; when I repeat the procedure and 
put a
breakpoint on fillbuf(), the execution does not break on fillbuf().

(trouble is I am not "set up" for building on Cygwin; otherwise I would 
build
 my "own" (not optimized) version of grep)

Regards,
Henri




This bug report was last modified 5 years and 135 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.