OS X 上的 grep -f 产生段错误 [英] grep -f on OS X produces segfault
问题描述
如果你有 Mac，试试这个:
If you've got a Mac, try this:
echo 'abcd*' > grepfile
echo 'abc$' >> grepfile
echo '^abc' >> grepfile
echo "fojeiwuroiuwet
ljfajsljkfabcdddjlfkajlkj
abcaaa
zzzabc
" | grep -f grepfile
这是版本:
$ grep --v
grep (BSD grep) 2.5.1-FreeBSD
这是一台跟上 Apple 软件更新的机器(2012 版的 rMBP)，所以我使用的是 10.8.4.
This is a machine (a rMBP of the 2012 flavor) that's kept up with Apple's software updates, so I am on 10.8.4.
我验证了从源代码编译的 GNU grep 不会遇到这个问题.确实是 2.14 版本，这是 2.5.1 之后的一大堆版本.
I verified that GNU grep compiled from source does not suffer from this problem. Indeed it is version 2.14, which is a whole lot of versions past 2.5.1.
但是，如果没有为每个正则表达式派生一个 grep 的非常低效的循环，如何才能完成针对一系列正则表达式测试某些输入的任务?
But how might one achieve the task of testing some input against a series of regexes otherwise, without some vastly inefficient loop that forks a grep for each regex?
我解决这个问题的方法类似于:while read REGEX;做 [[ ... =~ $REGEX ]] ... 完成 <正则表达式文件.
The approach I took to work around this was something akin to: while read REGEX; do [[ ... =~ $REGEX ]] ... done < regexfile.
问题:此版本的 grep 是否存在已知错误?我们如何设置我们的系统，以便它们能够与 grep 的正则表达式文件一起正常工作?
Question: Is this a known bug with this version of grep? How can we set up our systems so they will work properly with a file of regexes to grep?
更新:看起来有些人报告它工作正常(即使使用这个特定的 FreeBSD 2.5.1 grep).我可以采取哪些步骤来尝试找出它可能正在使用哪个 .so/.dylib?有人可以做一个 shasum/usr/bin/grep 并告诉我它是否适合你吗?(我不确定这是否会提供很多信息，但我想要的是我的计算机配置是否搞砸了，或者这是否是此版本软件的一些实际存在的问题.)
Update: Looks like some folks are reporting it works fine (even with this particular FreeBSD 2.5.1 grep). What are some steps I can take to try to figure out which .so/.dylib's it might be using? Can someone do a shasum /usr/bin/grep and tell me if it works for you? (I'm not sure if that would provide much information, but what I'm after is whether my computer's configuration is screwed up, or if this is some actual existing issue with this version of the software.)
$ shasum /usr/bin/grep
eac59389d09642decbb8551e2c975f795934bfbf /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=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
进一步调查:
$ 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)
我也重新启动了机器.它在 gdb 中重复地做同样的事情.
I have rebooted the machine as well. It repeatably does the same thing in gdb.
推荐答案
我在 MacBook Air 上安装了 OSX 10.8.4，您的示例默认情况下不会崩溃，但只有在添加 --color参数.
I've got OSX 10.8.4 on MacBook Air and your example doesn't crash by default, but only when adding --color parameter.
说明
当您将通配符(星号)与终端颜色混合时通常会发生这种崩溃，这是软件错误.
This crash usually happens when you're mixing wilcard (asterisk sign) with the terminal colours and this is the software bug.
还可以查看另一个更简单的示例:
Also check another simpler example:
echo 'abc*' | grep --color=auto -e ".*" -e a
这里似乎 --color=auto 有所作为(没有它或设置为 never，那么它不会崩溃).所以我假设你的 grep 默认在终端中使用颜色.
Here it seems that --color=auto makes the difference (without it or setting to never, then it doesn't crash).
So I assume that your grep is using colors in terminal by default.
解决方案
确保您的 grep 不是启用颜色的 grep 的别名，或者默认情况下未启用颜色.
Make sure that your grep is not an alias to the grep with colors enabled, or the colors are not enabled by default.
您始终可以尝试使用 --color=never 运行 grep.
You can always try to run grep with --color=never.
对于永久解决方案，我已报告错误报告:
For permanent solution, I've reported the bug report:
http://www.freebsd.org/cgi/query-pr.cgi?pr=181263
所以问题可以在软件本身中解决.
so the issue can be fixed in the software it-self.
如果您想访问更详细的崩溃日志，请转到控制台、显示日志列表并在用户诊断报告下找到崩溃日志.
If you'd like to access more detailed log of your crash, go to Console, Show Log List and find the crash log under User Diagnostic Reports.
例如:
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
<小时>
以下是有关崩溃的更详细说明:
Here is some more detailed explanation about the crash:
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
来源:http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026502.html
即使版本相同，在不同的 OSX 上似乎也有不同的 grep 二进制文件:
Also it seems that there are different grep binaries on different OSX even with the same version:
$ 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
这篇关于OS X 上的 grep -f 产生段错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
