Description of problem: Similar bug as one from 2016. https://bugzilla.redhat.com/show_bug.cgi?id=1391442 Do this: grep --only-matching --ignore-case --word-regexp --file /usr/share/dict/words /usr/share/doc/dovecot/ChangeLog Then watch your memory get exhausted (at least up to my 50GB RAM+swap). The problem seems to be big files passed in with --file. Strangely, unlike 2016, the haystack file also has to be big-ish. Upstream had fixed it after that. Upstream broke it again for Fedora 33's grep-3.4-5.fc33.x86_64. Upstream has it fixed in current git version 3.6.18-70517. Can we get F33 updated to the latest upstream? I didn't check if it's fixed in their last stable release version, but I can do that if required. Version-Release number of selected component (if applicable): grep-3.4-5.fc33.x86_64 How reproducible: always Steps to Reproduce: 1. grep --only-matching --ignore-case --word-regexp --file /usr/share/dict/words /usr/share/doc/dovecot/ChangeLog Actual results: Your RAM/swap get exhausted, no output, oom killer has to reap Expected results: Fixed version takes about 1.1GB RAM to run this and outputs the proper result Additional info: Fixed in upstream 3.6.18-70517 or earlier; between current and 3.4
I don't want to rebase grep in the stable release. We did it in the past and it introduced problems - grep is heavily used by various tools and also during the build process. It was part of the criticial path and rebase could lead to unexpected troubles. But I could try backporting the fix. Could you point me to the upstream commit? There are only few, but none seems related.
Ok. I did a git bisect to see what I could find. I had to do it in reverse though, where good was bad and bad was good because bisect doesn't let me say newest is good and oldest is bad. Weird. Anyhow, it's commit ae65513edc80a1b65f19264b9bed95d870602967 that fixes my problem. It's a bit puzzling, as my example is clearly using --only-matching which is the -o case the log mentions. I tested with and without -o and --color and no matter what, the bug doesn't manifest as long as I'm using ae65513edc80a1b65f19264b9bed95d870602967. It looks like 3.5 stable release would also work for me if perhaps it's less onerous to rebase to a stable. As for yanking a surgical patch, I'll try that tomorrow and we'll see how easy that is. Though looking at the diffs I can't fathom why this commit fixes my problem. Perhaps someone familiar with the code would understand. To double check, I recompiled the previous commit 34ada37baac651312b0e30092c086833a7223df6 and it does have my bug. So my good/bad determination should be correct.
I managed to make a patch against grep-3.4-5.fc33.src.rpm and it compiles and it fixes my bug. However rpmbuild -ba on the testing phase fails with 15 fails, but I have a hunch that's just my environment since I do this rpm stuff in my own quirky way. Can you run the patch on a Fedora-approved build setup and see if it passes the tests? If not, then backporting the required code is beyond my level of ability, as that means the fix is dependent on further commits. That would require someone familiar with the code.
Created attachment 1789028 [details] attempt to backport the commit changes that fix my bug But fails rpmbuild tests on my system.
(In reply to Trevor Cordes from comment #4) > Created attachment 1789028 [details] > attempt to backport the commit changes that fix my bug > > But fails rpmbuild tests on my system. Thanks, LGTM.
(In reply to Jaroslav Škarvada from comment #5) > (In reply to Trevor Cordes from comment #4) > > Created attachment 1789028 [details] > > attempt to backport the commit changes that fix my bug > > > > But fails rpmbuild tests on my system. > > Thanks, LGTM. Nope, it's not good, it's introducing new regression: FAIL word-delim-multibyte (exit status: 1) The test starts failing.
Created attachment 1791274 [details] Updated patch
FEDORA-2021-b70a99a8fb has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b70a99a8fb
FEDORA-2021-b70a99a8fb has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b70a99a8fb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b70a99a8fb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks for that, I'll test now and leave karma if it works. The patches were almost the same; I guessed some of the .h stuff was superfluous. But the latest git has that switcharoo in the order in GEAcompile... not sure why, or what else had to go with it to make it work. But it doesn't matter if your patch works!
FEDORA-2021-b70a99a8fb has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.