Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1872913 - zgrep -l / zgrep -L behaviour broken in Fedora 33+
Summary: zgrep -l / zgrep -L behaviour broken in Fedora 33+
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grep
Version: 33
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1863830
Blocks: 1872922
TreeView+ depends on / blocked
 
Reported: 2020-08-26 22:11 UTC by Adam Williamson
Modified: 2020-09-15 20:48 UTC (History)
7 users (show)

Fixed In Version: grep-3.4-5.fc34 grep-3.4-5.fc33 grep-3.4-5.eln103
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-02 19:48:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2020-08-26 22:11:04 UTC
`zgrep -l` and `zgrep -L` do not appear to work correctly in current Fedora 33 / Rawhide at all.

Check this:

[adamw@adam c]$ zgrep "U+0033" th.map.gz uz.map.gz
uz.map.gz:keycode 4 = U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three

that shows that only uz.map.gz contains the string "U+0033", which matches the result of both regular 'grep' after uncompressing the files manually:

[adamw@adam uc]$ grep "U+0033" th.map uz.map
uz.map:keycode 4 = U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three

and a manual inspection of the files. So far, so good. However, let's try out `zgrep -l` (which should print files *with* a match) and `zgrep -L` (which should print files *without* a match):

[adamw@adam c]$ zgrep -l "U+0033" th.map.gz uz.map.gz
uz.map.gz
[adamw@adam c]$ zgrep -L "U+0033" th.map.gz uz.map.gz
uz.map.gz

er...that's not right. The output of `-l` is correct in this case (though it's wrong in other cases I've tested), but the output of `-L` is clearly wrong - uz.map.gz *does* contain the string, the command should output 'th.map.gz'.

It's easy to produce all kinds of broken results by just experimenting with this with various files and strings.

this appears to work correctly in current Fedora 32:

[adamw@xps13k c]$ zgrep -l "U+0033" th.map.gz uz.map.gz
uz.map.gz
[adamw@xps13k c]$ zgrep -L "U+0033" th.map.gz uz.map.gz
th.map.gz

(xps13k is an F32 box). On further investigation, the cause is grep: F32 has grep-3.3-4.fc32.x86_64, F33 and Rawhide have grep-3.4-1.fc33.x86_64. If I downgrade grep to 3.3-4.fc32 on my F33 box, the bug stops happening.

I'm attaching sh -x logs from the broken and working cases. You can see somehow the return code of the grep run on line 208 of zgrep is not what it should be.

Now, would you like to play a game called "guess how this broken encrypted installs in Russian"? Because it did! :)

Comment 1 Adam Williamson 2020-08-26 22:26:42 UTC
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28105#29 looks a lot like the problem here, thus https://git.savannah.gnu.org/cgit/grep.git/commit/?id=0435ebca64fbafcd62008c991dd9377d8a792dfc should be the fix, only the timeframes don't seem to match: that thread claims the behaviour was changed in 3.2, but I see it change between 3.3 and 3.4. I can't see any downstream patches in either build that would affect this.

It seems the changes in the post-3.4 patch actually make the code a bit different from how it was in 3.3. So not sure if one of those apparently minor differences is the issue, but hum. I'm going to test patching grep with the apparent fix and see how that goes.

Comment 2 Adam Williamson 2020-08-26 22:59:32 UTC
It does seem that that patch fixes things, so I think upstream is just a bit off on the affected versions. One of the lines that's changed in the patch did change between 3.3 and 3.4, so I'm guessing that was the thing that was throwing zgrep off.

Now, however, there's another yak to shave: I can't do an official rebuild of grep because the test suite is coredumping on ppc64le and armv7hl. Nothing to do with this patch, it failed the 3.4-3 and 3.4-4 builds also (and 3.3 actually hits the same problem if you try and rebuild it on current F33).

Comment 3 Adam Williamson 2020-08-26 23:25:03 UTC
Marking as dependent on the FTBFS bug...

Comment 4 Fedora Update System 2020-08-28 18:09:08 UTC
FEDORA-2020-bc38b42372 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Adam Williamson 2020-08-28 18:15:30 UTC
Grr, update shouldn't have automatically closed this bug as it's filed against 33.

Comment 6 Fedora Update System 2020-08-28 21:36:22 UTC
FEDORA-2020-81fea835a4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4

Comment 7 Fedora Update System 2020-08-31 14:27:35 UTC
FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-81fea835a4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2020-09-02 19:48:45 UTC
FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Fedora Update System 2020-09-15 20:48:34 UTC
FEDORA-2020-0dcd106c75 has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.