Bug 251081
| Summary: | Grep Crashes with both «--after-context» «--max-count» Switches are Used | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | CrazyMihey <CrazyMihey> | ||||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | igorkolesnik, kevans | ||||||
| Priority: | --- | ||||||||
| Version: | 12.2-RELEASE | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Looks like it strips out the trailing eol character when calling execute in prpending(). Inside execute memchr() fails to find eol and returns NULL. This occurs in 13.0-CURRENT as well. BSD grep does not contain such bug. Attached is a proposed patch. Created attachment 219672 [details]
Include eol when calling execute in prpending
(In reply to Igor Kolesnik from comment #2) Great & Quickly! But ToDay (ReVision 367710) I did not see This Change neither in «RelEng 12.2», not in «Head» (Current). SVN Says, «/[base]/head/gnu/usr.bin/grep/grep.c» File is 7 Years old. Do You Recommend to Apply Your Patch by MySelf after Source DownLoad? Sorry, maybe I do not understand the Development Stadies of BugFixing, will This Patch be Allpied to Current or RelEng Tree? Or maybe it is better not to Use the Bugging-Flags together? I did not touch WITH_BSD_GREP/WITHOUT_GNU_GREP/WITH_GNU_GREP_COMPAT in «etc\src.conf», so it seems, I newer used «BSD grep»: always try to use Distribution-Default Utilities first. Thank You! (In reply to CrazyMihey from comment #3) I'm not a FreeBSD developer. The fix only exists as the proposed patch attached to this ticket. Actually, I don't know how it goes further from here. I searched for bugs related to grep https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=grep&list_id=387710 and found that this bug already reported a quite time ago https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193835 Also, it seems that gnugrep is going to be dropped away in favor of bsdgrep. And there is a port/package textproc/gnugrep which is free of this bug. A commit references this bug: Author: kevans Date: Tue Dec 8 14:05:27 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 Missed in previous sweeps for gnugrep bugs- xlosing now. Thanks for the report! All supported versions now use bsdgrep. |
Created attachment 219606 [details] Grep Memory Dump 12.2 x64 FreeBSD Grep Utility Crushes in a case of simultaneously specifying two Switches: «--after-context=NUM» (-A NUM) and «--max-count=NUM» (-m NUM). This happens when Russian Language (for Example) is Used. The Example to ReProduce this Error (EveryOne can Try, if Brave enough): # id -c russian #grep --after-context="10" --max-count="2" "" "/etc/passwd" # $FreeBSD: releng/12.2/etc/master.passwd 359447 2020-03-30 17:07:05Z brooks $ # Segmentation fault (стек памяти сброшен на диск) or, without specifying the «Russian» LogIn Class (ReProduced on any System): # env LANG="ru_RU.UTF-8" grep --after-context="10" --max-count="2" "" "/etc/passwd" || printf "Error Number: %u (0x%.2X).\n" "${?}" "${?}" # $FreeBSD: releng/12.2/etc/master.passwd 359447 2020-03-30 17:07:05Z brooks $ # Segmentation fault (стек памяти сброшен на диск) Error Number: 139 (0x8B). # Looks like 0x80 + 0x0B: «SIGSEGV». shows the same Result. «egrep» does the same. # grep --version grep (GNU grep) 2.5.1-FreeBSD This Issue was found with these Systems: ● FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 GENERIC amd64 ● FreeBSD 12.1-RELEASE-p2 r358570 CrazyBook i386 ● FreeBSD 12.2-RELEASE r366954 GENERIC i386 ● FreeBSD 12.2-RELEASE r366954 GENERIC amd64 This is not a Critical Error, but IMHO, Developers should Know about It. Thank You and Sorry, if It is not Important.