grep -f na OS X produkuje segfault

Question

Jeśli masz komputer Mac, spróbuj tego:

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

Oto wersja:

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

Jest to maszyna (a rMBP z 2012 roku smak), który jest aktualizowany przez aktualizacje oprogramowania Apple, więc jestem na 10.8.4.

Sprawdziłem, że GNU grep skompilowany ze źródła nie cierpi z powodu tego problemu. Rzeczywiście jest to wersja 2.14, która jest dużo wersji po 2.5.1.

Ale w jaki sposób można wykonać zadanie testowania niektórych danych wejściowych w odniesieniu do serii wyrażeń regularnych w inny sposób, bez jakiejś bardzo nieefektywnej pętli, która przesyła grep dla każdego wyrażenia regularnego?

Edycja: podejście, które podjąłem, aby obejść ten problem, było podobne do: while read REGEX; do [[ ... =~ $REGEX ]] ... done < regexfile.

Pytanie: Czy jest to znany błąd w tej wersji grep? Jak możemy skonfigurować nasze systemy, aby działały poprawnie z plikiem wyrażeń regularnych do grep?

Aktualizacja: Wygląda na to, że niektórzy ludzie zgłaszają, że działa dobrze (nawet z tym szczególnym grepem FreeBSD 2.5.1). Jakie kroki mogę podjąć, aby spróbować dowiedzieć się, który plik .so/.dylib może być używany? Czy ktoś może zrobić shasum /usr/bin/grep i powiedzieć mi, czy to działa dla Ciebie? (Nie jestem pewien, czy to by dostarczyć dużo informacji, ale co mi po tym, czy konfiguracja mojego komputera jest wkręca się, czy to jakiś rzeczywisty problem istniejący w tej wersji oprogramowania.)

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

Oto więcej informacji:

$ 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 

Dalsze badania:

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

I ponownym uruchomieniu urządzenia, jak również. Powtarzalnie robi to samo w gdb.

Answer 1

Mam system OSX 10.8.4 na MacBooku Air, a Twój przykład nie powoduje awarii domyślnie, ale tylko przy dodawaniu parametru --color.

Wyjaśnienie

Ta ruina zwykle bywa, gdy jesteś mieszanie wilcard znak (gwiazdka) z kolorami zacisków i jest to błąd oprogramowania.

sprawdzić również inny prostszy przykład:

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

Tutaj wydaje się, że --color=auto robi różnicę (lub bez niej ustawienie never, to nie psuje). Zakładam więc, że twój grep domyślnie używa kolorów w terminalu.

Rozwiązanie

Upewnij się, że grep nie jest aliasem do grep z włączoną kolory lub kolory nie są domyślnie włączone.

Zawsze możesz spróbować uruchomić grep z --color=never.

uzyskać trwałe rozwiązanie, jakie zgłosił raport o błędzie:

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

więc problem może być rozwiązany w oprogramowaniu to-samo.

---

Jeśli chcesz uzyskać dostęp do bardziej szczegółowy dziennik swojego wypadku, przejdź do konsoli, Pokaż listę wszystkich raportów i odnaleźć dziennik katastrofy pod użytkownika raportów diagnostycznych.

Np

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 

---

Oto bardziej szczegółowe wyjaśnienie o katastrofie:

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 

Źródło: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026502.html

---

Ponadto wydaje się, że istnieją różne sol binarne rep na różne OSX nawet o tej samej wersji:

$ 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