Bug 223031 - bsdgrep behaves incorrectly when given multiple patterns
Summary: bsdgrep behaves incorrectly when given multiple patterns
Status: Closed DUPLICATE of bug 209116
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.3-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-15 15:39 UTC by Jonathan de Boyne Pollard
Modified: 2017-10-16 14: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 Jonathan de Boyne Pollard 2017-10-15 15:39:38 UTC 
See https://unix.stackexchange.com/questions/398223/ for how to replicate this.

Some investigation reveals that this is apparently down to the pmatch object in the procline() function not being used properly.

In the outer loop, it is being used to track the start and end position within the current input line.  However, if multiple patterns are provided, in the inner loop it is overwritten by the first call to fastexec()/regexec() and not reinitialized with st and l->len for the next.

The (re)initialization code for pmatch.rm_so and pmatch.rm_eo needs to be moved down into the inner loop, so that it is set correctly for every pattern, not just for the first one.

This also means that the

if (st == (size_t)pmatch.rm_so)

code in the outer loop is probably wrong, too, as that will only detect the output of the last fastexec()/regexec() call for the last of multiple patterns.  Perhaps there should be one pmatch object per pattern.
Comment 1 Kyle Evans freebsd_committer freebsd_triage 2017-10-16 00:34:05 UTC 
Hi,

Do you know offhand if this reproduces on -CURRENT (bsdgrep 2.6.0-FreeBSD)? I've made some major overhauls to bsdgrep that haven't hit stable/10 yet.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2017-10-16 01:21:04 UTC 
Does not reproduce on -current using the provided instructions:

% cat file
file
types
extensions 
% cat stopwords
i
file
types
% grep -vwFf stopwords file
extensions 
%
Comment 3 Kyle Evans freebsd_committer freebsd_triage 2017-10-16 01:56:37 UTC 
(In reply to Ed Maste from comment #2)

Excellent, I'll go through tomorrow and pinpoint the commit(s) that would've fixed  this one. I think I'll have some time to MFC everything to stable/10 soon.
Comment 4 Jonathan de Boyne Pollard 2017-10-16 05:31:35 UTC 
base r316477?  I am not using -CURRENT.  I'll update StackExchange if you confirm which revision it is that fixed this.
Comment 5 Kyle Evans freebsd_committer freebsd_triage 2017-10-16 13:21:46 UTC 
(In reply to Jonathan de Boyne Pollard from comment #4)

Indeed, base r316477 fixed this particular error. There were some further fixes for -w -v matching errors in base r317665, but this one was addressed in the former.
Comment 6 Kyle Evans freebsd_committer freebsd_triage 2017-10-16 14:04:30 UTC 
I'm going to go ahead and close this as duplicate of PR 209116 (bsdgrep -Fxf failing if earlier non-match is a sub-prefix of the actual match) -- thanks for your report and detailed assessment!

*** This bug has been marked as a duplicate of bug 209116 ***