Bug 197531
| Summary: | textproc/bsdgrep: segfaults using grep --color -f | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jason McSweeney <loadzero.dev> | ||||
| Component: | Individual Port(s) | Assignee: | Kyle Evans <kevans> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | emaste, kenorb, kevans | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(gabor) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195763 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197555 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181263 |
||||||
| Attachments: |
|
||||||
|
Description
Jason McSweeney
2015-02-11 03:54:37 UTC
Auto-assigned to maintainer gabor@FreeBSD.org This additional test case also trips it up - but it segfaults inside printline echo i860 > /tmp/p ./work/grep-20111002/grep --color -e i860 -e i86 /tmp/p I believe it is related to this bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197555 (gdb) r Starting program: /usr/ports/textproc/bsdgrep/work/grep-20111002/grep --color -e i860 -e i86 /tmp/p i860 i860 Program received signal SIGSEGV, Segmentation fault. 0x00000008011d0a60 in memchr () from /lib/libc.so.7 (gdb) bt #0 0x00000008011d0a60 in memchr () from /lib/libc.so.7 #1 0x00000008011d0599 in fwrite () from /lib/libc.so.7 #2 0x00000008011d043d in fwrite () from /lib/libc.so.7 #3 0x0000000000406190 in printline (line=0x7fffffffe8a8, sep=58, matches=0x7fffffffe740, m=2) at util.c:469 #4 0x0000000000405d81 in procline (l=0x7fffffffe8a8, nottext=0) at util.c:366 #5 0x0000000000405455 in procfile (fn=0x7fffffffed73 "/tmp/p") at util.c:231 #6 0x0000000000404152 in main (argc=7, argv=0x7fffffffeac0) at grep.c:719 Created attachment 169441 [details]
Test file which crashes with grep
This file crashes with: grep --color=auto -e test -e test test.info
Same is happening on OS X with grep (BSD grep) 2.5.1-FreeBSD $ \grep --color=auto -e test -e test test.info ... Segmentation fault: 11 Check the attached file to test. Related blog post: http://blog.loadzero.com/blog/digging-deeper-into-the-grep-segfault/ FWIW- The patch in this PR seems to clear up this issue as well: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195763 A commit references this bug: Author: emaste Date: Mon Apr 3 23:16:51 UTC 2017 New revision: 316477 URL: https://svnweb.freebsd.org/changeset/base/316477 Log: bsdgrep: fix matching behaviour - Set REG_NOTBOL if we've already matched beginning of line and we're examining later parts - For each pattern we examine, apply it to the remaining bits of the line rather than (potentially) smaller subsets - Check for REG_NOSUB after we've looked at all patterns initially matching the line - Keep track of the last match we made to later determine if we're simply not matching any longer or if we need to proceed another byte because we hit a zero-length match - Match the earliest and longest bit of each line before moving the beginning of what we match to further in the line, past the end of the longest match; this generally matches how gnugrep(1) seems to behave, and seems like pretty good behavior to me - Finally, bail out of printing any matches if we were set to print all (empty pattern) but -o (output matches) was set PR: 195763, 180990, 197555, 197531, 181263, 209116 Submitted by: "Kyle Evans" <kevans91@ksu.edu> Reviewed by: cem MFC after: 1 month Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D10104 Changes: head/usr.bin/grep/util.c A commit references this bug: Author: emaste Date: Wed Apr 5 18:41:47 UTC 2017 New revision: 316536 URL: https://svnweb.freebsd.org/changeset/base/316536 Log: bsdgrep: create additional tests for coverage on recent fixes Create additional tests to cover regressions that were discovered by PRs linked to reviews D10098, D10102, and D10104. It is worth noting that neither bsdgrep(1) nor gnugrep(1) in the base system currently pass all of these tests, and gnugrep(1) not quite being up to snuff was also noted in at least one of the PRs. PR: 175314 202022 195763 180990 197555 197531 181263 209116 Submitted by: Kyle Evans <kevans91@ksu.edu> Reviewed by: cem, ngie, emaste MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D10112 Changes: head/contrib/netbsd-tests/usr.bin/grep/d_color_a.in head/contrib/netbsd-tests/usr.bin/grep/d_color_a.out head/contrib/netbsd-tests/usr.bin/grep/d_color_b.in head/contrib/netbsd-tests/usr.bin/grep/d_color_b.out head/contrib/netbsd-tests/usr.bin/grep/d_color_c.out head/contrib/netbsd-tests/usr.bin/grep/d_escmap.in head/contrib/netbsd-tests/usr.bin/grep/d_f_file_empty.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_a.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_a.out head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_b.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_b.out head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_c.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_c.out head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_d.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_e.in head/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_e.out head/contrib/netbsd-tests/usr.bin/grep/t_grep.sh head/usr.bin/grep/tests/Makefile A commit references this bug: Author: kevans Date: Wed Aug 16 00:12:25 UTC 2017 New revision: 322555 URL: https://svnweb.freebsd.org/changeset/base/322555 Log: bsdgrep: Fix matching behavior and add regression tests MFC r316477: bsdgrep: fix matching behaviour - Set REG_NOTBOL if we've already matched beginning of line and we're examining later parts - For each pattern we examine, apply it to the remaining bits of the line rather than (potentially) smaller subsets - Check for REG_NOSUB after we've looked at all patterns initially matching the line - Keep track of the last match we made to later determine if we're simply not matching any longer or if we need to proceed another byte because we hit a zero-length match - Match the earliest and longest bit of each line before moving the beginning of what we match to further in the line, past the end of the longest match; this generally matches how gnugrep(1) seems to behave, and seems like pretty good behavior to me - Finally, bail out of printing any matches if we were set to print all (empty pattern) but -o (output matches) was set MFC r316489: bsdgrep: Initialize vars to avoid a false positive GCC warning MFC r316491: bsdgrep: revert color changes from r316477 r316477 changed the color output to match exactly the in-tree GNU grep, but introduces unnecessary escape sequences. MFC r316536: bsdgrep: create additional tests for coverage on recent fixes Create additional tests to cover regressions that were discovered by PRs linked to reviews D10098, D10102, and D10104. It is worth noting that neither bsdgrep(1) nor gnugrep(1) in the base system currently pass all of these tests, and gnugrep(1) not quite being up to snuff was also noted in at least one of the PRs. MFC r317052: bsdgrep: fix zero-length matches without the -o flag r316477 broke zero-length matches when not using the -o flag, by skipping over them entirely. Add a regression test so that it doesn't break again in the future. PR: 175314, 180990, 181263, 195763, 197531, 197555, 202022, 209116 Approved by: emaste (mentor, blanket MFC) Relnotes: yes Changes: _U stable/11/ stable/11/contrib/netbsd-tests/usr.bin/grep/d_color_a.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_color_a.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_color_b.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_color_b.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_color_c.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_escmap.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_f_file_empty.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_a.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_a.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_b.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_b.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_c.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_c.out stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_d.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_e.in stable/11/contrib/netbsd-tests/usr.bin/grep/d_oflag_zerolen_e.out stable/11/contrib/netbsd-tests/usr.bin/grep/t_grep.sh stable/11/usr.bin/grep/tests/Makefile stable/11/usr.bin/grep/util.c A commit references this bug: Author: kevans Date: Thu Apr 19 18:22:47 UTC 2018 New revision: 467795 URL: https://svnweb.freebsd.org/changeset/ports/467795 Log: [PATCH] textproc/bsdgrep: Update to 2.6.0 and set LICENSE The following list of changes are roughly what has occurred since the last update: Features: - With bsdgrep -r, the working directory is implied if no directory is specified - bsdgrep will now behave as bsdgrep -r does when it's named rgrep - bsdgrep now understands -z/--null-data to use \0 as EOL - GNU regex compatibility is now indicated with a "GNU compatible" in the version string Fixes: - --mmap no longer hangs when coming across an EOF without an accompanying EOL - -o/--color matching generally improved, now produces earliest / longest matches - Context output now more closely aligns with GNU grep - Zero-length matches no longer exhibit broken behavior - Every output line now honors -b/-H/-n flags Other fixes are also present. While here, move to the version as reported by `grep -V` -- I intend to bump the version in base sensible as bugfixes/features roll in. Tested with: Poudriere (amd64, head) Tested with: Poudriere (amd64, 11.1) Tested with: Poudriere (amd64, 10.4) Glanced at by: Portlint -AC PR: 227639, 197531 Approved by: portmgr (feld) Changes: head/textproc/bsdgrep/Makefile head/textproc/bsdgrep/distinfo head/textproc/bsdgrep/files/patch-Makefile head/textproc/bsdgrep/pkg-plist This has now been addressed in both ports and base, so I am closing it. Unfortunately I don't think this can be MFH'd to 2018Q2, but it will certainly appear in 2018Q3. |
