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.
* 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
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.
Is it reasonable to just switch BSD_GREP_FASTMATCH to default no at this point?
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)
/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)
(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"
(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.