Bug 222333 - grep core dumped on search of /usr/src
Summary: grep core dumped on search of /usr/src
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-14 17:57 UTC by Zak
Modified: 2021-08-20 17:04 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Zak 2017-09-14 17:57:30 UTC 
running: 

grep -r "iicbus_if.h" 

from /usr/src resulted in a core dump. lldb backtrace:

lldb `which grep` -c grep.core
(lldb) target create "/usr/bin/grep" --core "grep.core"
Core file '/home/emaste/src/freebsd-wip/grep.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'grep', stop reason = signal SIGSEGV
  * frame #0: 0x000000000020c148 grep`tre_match_fast(fg=0x0000084755082500, data=0x00000847550cc000, len=<unavailable>, type=STR_MBS, nmatch=1, pmatch=0x00007fffffffe1b0, eflags=<unavailable>) at tre-fastmatch.c:987
    frame #1: 0x0000000000207920 grep`tre_fastexec at fastmatch.c:134
    frame #2: 0x00000000002078c0 grep`tre_fastexec(preg=0x0000084755082500, string=<unavailable>, nmatch=1, pmatch=0x00007fffffffe1b0, eflags=4) at fastmatch.c:145
    frame #3: 0x0000000000206b6a grep`procline(pc=0x00007fffffffe318) at util.c:474
    frame #4: 0x00000000002065d6 grep`procfile(fn=<unavailable>) at util.c:280
    frame #5: 0x00000000002062ad grep`grep_tree(argv=<unavailable>) at util.c:188
    frame #6: 0x0000000000205c16 grep`main(argc=<unavailable>, argv=0x00007fff00000002) at grep.c:787
    frame #7: 0x000000000020417f grep`_start + 383


Comment 1 Kyle Evans freebsd_committer freebsd_triage 2017-09-14 18:25:13 UTC 
I'll dig into this when I get some time. In the meantime, if it's feasible, this doesn't occur when compiled WITHOUT_BSD_GREP_FASTMATCH; those bits tend to be a little bit buggy still, unfortunately (=() and I'd really like to do away with them.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2017-09-14 18:48:23 UTC 
Is it reasonable to just switch BSD_GREP_FASTMATCH to default no at this point?
Comment 3 Ed Maste freebsd_committer freebsd_triage 2017-09-15 02:34:38 UTC 
I switched BSD_GREP_FASTMATCH to default to no in my WIP branch and then the build fails:

/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/tmp/usr/bin/ld: error: undefined symbol: tre_fastncomp
>>> referenced by grep.c:764 (/scratch/tmp/emaste/freebsd/usr.bin/grep/grep.c:764)
>>>               grep.o:(main)

/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/tmp/usr/bin/ld: error: undefined symbol: tre_fastexec
>>> referenced by util.c:474 (/scratch/tmp/emaste/freebsd/usr.bin/grep/util.c:474)
>>>               util.o:(procline)
Comment 4 Kyle Evans freebsd_committer freebsd_triage 2017-09-15 13:35:06 UTC 
(In reply to Ed Maste from comment #2)

I'm thinking so. I was afraid that libgnuregex might have more bugs that we hadn't uncovered that will popup when TRE isn't covering some of the more basic expressions, but it occurs to me now that we switched -HEAD to default GNU_GREP_COMPAT to 'no' so that's a non-issue.


(In reply to Ed Maste from comment #3)

Huh? That makes no sense. =( Is this WITH_META_MODE or something else that might have goofed it up? The first referenced line (grep.c:764) is behind an #ifndef WITHOUT_FASTMATCH, which is put in CFLAGS at Makefile:24 if MK_BSD_GREP_FASTMATCH != "yes"
Comment 5 Ed Maste freebsd_committer freebsd_triage 2017-09-15 20:13:20 UTC 
(In reply to Kyle Evans from comment #4)
Sigh, this was due to stale object files. I thought I had cleaned out objdir first but it seems not.
Comment 6 Piotr Pawel Stefaniak freebsd_committer freebsd_triage 2021-08-20 17:04:40 UTC 
FASTMATCH is gone