grep -f su OS X produce segfault

Question

Se avete un Mac, provate questo:

echo 'abcd*' > grepfile 
echo 'abc$' >> grepfile 
echo '^abc' >> grepfile 
echo "fojeiwuroiuwet\nljfajsljkfabcdddjlfkajlkj\nabcaaa\nzzzabc\n" | grep -f grepfile 

Ecco la versione:

$ grep --v 
grep (BSD grep) 2.5.1-FreeBSD 

Questa è una macchina (una rMBP del 2012 flavor) che è tenuto aggiornato con gli aggiornamenti software di Apple, quindi sono su 10.8.4.

Ho verificato che GNU grep compilato dalla sorgente non soffre di questo problema. In effetti è la versione 2.14, che è un sacco di versioni precedenti alla 2.5.1.

Ma come si potrebbe ottenere il compito di testare alcuni input su una serie di regex in caso contrario, senza un ciclo molto inefficiente che genera un grep per ogni regex?

Modifica: l'approccio che ho seguito per risolvere questo problema era simile a: while read REGEX; do [[ ... =~ $REGEX ]] ... done < regexfile.

Domanda: Si tratta di un bug noto con questa versione di grep? Come possiamo configurare i nostri sistemi in modo che funzionino correttamente con un file di regex su grep?

Aggiornamento: Sembra che alcuni utenti stiano segnalando che funziona correttamente (anche con questo particolare FreeBSD 2.5.1 grep). Quali sono alcuni passi che posso fare per cercare di capire quale .so/.dylib potrebbe usare? Qualcuno può fare un shasum /usr/bin/grep e dirmi se funziona per te? (Non sono sicuro se questo sarebbe fornire molte informazioni, ma quello che sto cercando è se la configurazione del mio computer è avvitato, o se questo è un problema effettivo esistente con questa versione del software.)

$ shasum /usr/bin/grep 
eac59389d09642decbb8551e2c975f795934bfbf /usr/bin/grep 

Ecco ulteriori informazioni:

$ codesign -dvvv /usr/bin/grep 
Executable=/usr/bin/grep 
Identifier=com.apple.zgrep 
Format=Mach-O thin (x86_64) 
CodeDirectory v=20100 size=224 flags=0x0(none) hashes=6+2 location=embedded 
Hash type=sha1 size=20 
CDHash=93b823c000188f8737653d8333c90a6db9361d70 
Signature size=4064 
Authority=Software Signing 
Authority=Apple Code Signing Certification Authority 
Authority=Apple Root CA 
Info.plist=not bound 
Sealed Resources=none 
Internal requirements count=2 size=208 

ulteriori indagini:

$ gdb /usr/bin/grep 
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Thu Nov 15 10:42:43 UTC 2012) 
Copyright 2004 Free Software Foundation, Inc. 
GDB is free software, covered by the GNU General Public License, and you are 
welcome to change it and/or distribute copies of it under certain conditions. 
Type "show copying" to see the conditions. 
There is absolutely no warranty for GDB. Type "show warranty" for details. 
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done 

(gdb) start -f grepfile 
Function "main" not defined. 
Make breakpoint pending on future shared library load? (y or [n]) 
Starting program: /usr/bin/grep -f grepfile 
Reading symbols for shared libraries +++.............................. done 
abc 
abc 

Program received signal EXC_BAD_ACCESS, Could not access memory. 
Reason: KERN_INVALID_ADDRESS at address: 0x0000000101000000 
0x00007fff89b5d1b3 in memchr() 
(gdb) where 
#0 0x00007fff89b5d1b3 in memchr() 
#1 0x00007fff89b8e45a in __sfvwrite() 
#2 0x00007fff89b8e861 in fwrite() 
#3 0x0000000100003138 in _mh_execute_header() 
#4 0x0000000100002988 in _mh_execute_header() 
#5 0x0000000100001c28 in _mh_execute_header() 
#6 0x00007fff8e2d57e1 in start() 
(gdb) 

ho ripartito la macchina pure. Ripetutamente fa la stessa cosa in gdb.

Answer 1

Ho OSX 10.8.4 su MacBook Air e l'esempio non si arresta in modo anomalo per impostazione predefinita, ma solo quando si aggiunge il parametro --color.

Spiegazione

Questo incidente accade di solito quando si sta mescolando wildcard (segno asterisco) con i colori del terminale e questo è il bug del software.

verificare anche un altro esempio più semplice:

echo 'abc*' | grep --color=auto -e ".*" -e a 

Qui sembra che --color=auto fa la differenza (senza di essa o l'impostazione di never, allora non va in crash). Quindi presumo che il tuo grep stia usando i colori nel terminale di default.

Soluzione

Assicurarsi che il grep non è un alias per il grep con i colori abilitati, oppure i colori non sono abilitate di default.

Si può sempre provare a eseguire grep con --color=never.

Per soluzione permanente, ho riportato il bug report:

http://www.freebsd.org/cgi/query-pr.cgi?pr=181263

in modo che il problema può essere risolto nel software da-sé.

---

Se desideri accedere registro più dettagliato del crash, andare al Console, Mostra elenco registro e trovare il registro blocchi sotto Rapporti diagnostica utente.

Esempio:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 
0 libsystem_c.dylib    0x00007fff8a8da1b3 memchr + 15 
1 libsystem_c.dylib    0x00007fff8a90b45a __sfvwrite + 578 
2 libsystem_c.dylib    0x00007fff8a90b861 fwrite + 114 
3 grep       0x000000010a4a3138 0x10a4a0000 + 12600 
4 grep       0x000000010a4a2988 0x10a4a0000 + 10632 
5 grep       0x000000010a4a1c28 0x10a4a0000 + 7208 
6 libdyld.dylib     0x00007fff8daf77e1 start + 1 

---

Ecco qualche spiegazione più dettagliate circa l'incidente:

A quick test 

    $ env -i bsdgrep -Fi without_nls usr.bin/grep/grep.c 
    $ env -i gnugrep -Fi without_nls usr.bin/grep/grep.c 
    #ifndef WITHOUT_NLS 
    #ifndef WITHOUT_NLS 
    #ifndef WITHOUT_NLS 

shows that bsd fgrep already fails to ignore case. And if you throw 
a few more options to the mix it'd crash, e.g. 

    $ env -i LC_CTYPE=en_US.UTF-8 TERM=xterm bsdgrep --color -Fir without_nls usr.bin/grep/ 
    [...] 
    Program received signal SIGSEGV, Segmentation fault. 
    0x0000000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297) at /usr/src/lib/libc/string/memchr.c:48 
    48        if (*p++ == (unsigned char)c) 
    (gdb) bt 
    #0 0x0000000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297) at /usr/src/lib/libc/string/memchr.c:48 
    #1 0x0000000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffffffd8f0) at /usr/src/lib/libc/stdio/fvwrite.c:170 
    #2 0x0000000801007698 in fwrite (buf=0x608c03, size=18446744073709551606, count=1, fp=0x801247770) 
     at /usr/src/lib/libc/stdio/fwrite.c:95 
    #3 0x0000000000405498 in printline (line=0x7fffffffdb70, sep=58, matches=0x7fffffffd990, m=9) 
     at /usr/src/usr.bin/grep/util.c:500 
    #4 0x0000000000404f51 in procline (l=0x7fffffffdb70, nottext=0) at /usr/src/usr.bin/grep/util.c:381 
    #5 0x000000000040489f in procfile (fn=0x80140b600 "usr.bin/grep/nls/es_ES.ISO8859-1.msg") at /usr/src/usr.bin/grep/util.c:239 
    #6 0x00000000004044d7 in grep_tree (argv=0x7fffffffdd30) at /usr/src/usr.bin/grep/util.c:163 
    #7 0x0000000000403ea9 in main (argc=5, argv=0x7fffffffdd10) at /usr/src/usr.bin/grep/grep.c:689 

Fonte: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026502.html

---

Inoltre sembra che ci sono diversi g rep binari su OSX diversi anche con la stessa versione:

$ grep --v 
grep (BSD grep) 2.5.1-FreeBSD 
$ shasum /usr/bin/grep 
350ee11e1868e18c9707ea7035184a114f40badf /usr/bin/grep 
$ codesign -dvvv /usr/bin/grep 
Executable=/usr/bin/grep 
Identifier=com.apple.zgrep 
Format=Mach-O thin (x86_64) 
CodeDirectory v=20100 size=224 flags=0x0(none) hashes=6+2 location=embedded 
Hash type=sha1 size=20 
CDHash=1537b3ed49878d5d18482859a37318164a2a40f1 
Signature size=4064 
Authority=Software Signing 
Authority=Apple Code Signing Certification Authority 
Authority=Apple Root CA 
Info.plist=not bound 
Sealed Resources=none 
Internal requirements count=2 size=176