grep segfault create a file test.txt ------------- text text <blank line> text text ------------- run command: grep -m 1 -A 2 -e '^$' test.txt > Segmentation Fault (core dumped) in file test.txt add to end blank line run grep again. Result: none Change -m1 to -m2 Result: all is ok
http://dpaste.com/3VPJ869
Copied gdb output from link, because it will expired through 1 day. main:[~] %> gdb grep GNU gdb 6.1.1 [FreeBSD] 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 "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r -m 1 -A 2 -e '^$' text.test Starting program: /usr/bin/grep -m 1 -A 2 -e '^$' text.test (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0000000800fb1a60 in memchr () from /lib/libc.so.7 (gdb) thread apply all bt (gdb) bt #0 0x0000000800fb1a60 in memchr () from /lib/libc.so.7 #1 0x000000000040ff92 in ?? () #2 0x000000000040d090 in ?? () #3 0x000000000040c5c9 in ?? () #4 0x000000000040bd52 in ?? () #5 0x000000000040260f in ?? () #6 0x0000000800633000 in ?? () #7 0x0000000000000000 in ?? () (gdb) f 0 #0 0x0000000800fb1a60 in memchr () from /lib/libc.so.7 (gdb)
This is indeed an issue with gnugrep, and not with libgnuregex. This one goes away when bsdgrep is installed as /usr/bin/grep, and can safely go away at that time.
A commit references this bug: Author: kevans Date: Tue Dec 8 14:05:26 UTC 2020 New revision: 368439 URL: https://svnweb.freebsd.org/changeset/base/368439 Log: src.opts.mk: switch to bsdgrep as /usr/bin/grep This has been years in the making, and we all knew it was bound to happen some day. Switch to the BSDL grep implementation now that it's been a little more thoroughly tested and theoretically supports all of the extensions that gnugrep in base had with our libregex(3). Folks shouldn't really notice much from this update; bsdgrep is slower than gnugrep, but this is currently the price to pay for fewer bugs. Those dissatisfied with the speed of grep and in need of a faster implementation should check out what textproc/ripgrep and textproc/the_silver_searcher can do for them. I have some WIP to make bsdgrep faster, but do not consider it a blocker when compared to the pros of switching now (aforementioned bugs, licensing). PR: 228798 (exp-run) PR: 128645, 156704, 166842, 166862, 180937, 193835, 201650 PR: 232565, 242308, 246000, 251081, 191086, 194397 Relnotes: yes, please Changes: head/share/mk/src.opts.mk
Still happens on 12.4-STABLE with GNU grep 2.5.1 (stable/12 branch EoLs on 31 December 2023).
Fixed by the switch to BSD grep in FreeBSD 13+. This is not fixed in 12.x but as there are no more releases to come it will unfortunately remain unfixed there.