Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Segfault when passing a before and after rpm #43

Closed
morucci opened this issue Sep 12, 2019 · 2 comments
Closed

Segfault when passing a before and after rpm #43

morucci opened this issue Sep 12, 2019 · 2 comments

Comments

@morucci
Copy link
Contributor

morucci commented Sep 12, 2019

Hi David,

I experienced a segfault with rpminspect, here is my log:

➜  python-gear git:(master) ✗ koji latest-pkg --quiet rawhide python-gear | cut -d' ' -f1
python-gear-0.14.0-5.fc32
➜  python-gear git:(master) ✗ rpminspect -v -f python-gear-0.14.0-5.fc32
Downloading https://kojipkgs.fedoraproject.org/packages/python-gear/0.14.0/5.fc32/noarch/python3-gear-0.14.0-5.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gear/0.14.0/5.fc32/src/python-gear-0.14.0-5.fc32.src.rpm...

Keeping working directory: /var/tmp/rpminspect/python-gear-0.14.0-5.fc32
➜  python-gear git:(master) ✗ rpminspect -v -k /var/tmp/rpminspect/python-gear-0.14.0-5.fc32/noarch/python3-gear-0.14.0-5.fc32.noarch.rpm ./python3-gear-0.14.0-6.fc32.noarch.rpm
[1]    26790 segmentation fault (core dumped)  rpminspect -v -k  ./python3-gear-0.14.0-6.fc32.noarch.rpm
➜  python-gear git:(master) ✗

The core dump from journalctl:

sept. 12 21:43:52 fbo-laptop systemd-coredump[26792]: Process 26790 (rpminspect) of user 1001 dumped core.
                                                      
                                                      Stack trace of thread 26790:
                                                      #0  0x00007feb2f6e0ef2 __strcmp_avx2 (libc.so.6)
                                                      #1  0x00007feb2f88ad85 inspect_metadata (librpminspect.so.0)
                                                      #2  0x0000560498a3332e n/a (rpminspect)
                                                      #3  0x00007feb2f5a8413 __libc_start_main (libc.so.6)
                                                      #4  0x0000560498a3381e n/a (rpminspect)

The "after build" python-gear package has been built outside of koji, via fedpkg mockbuild, this is a simple change:

➜  python-gear git:(master) ✗ git --no-pager diff python-gear.spec
diff --git a/python-gear.spec b/python-gear.spec
index 5c13d24..0b2a14c 100644
--- a/python-gear.spec
+++ b/python-gear.spec
@@ -3,7 +3,7 @@
 
 Name: python-%{srcname}
 Version: 0.14.0
-Release: 5%{?dist}
+Release: 6%{?dist}
 Summary: Pure Python Async Gear Protocol Library
 
 License: ASL 2.0
@@ -25,7 +25,7 @@ BuildRequires: python3-testresources
 BuildRequires: python3-testscenarios
 
 %global _description\
-python-gear implements an asynchronous event-driven interface to Gearman.\
+python-gear s implements an asynchronous event-driven interface to Gearman.\
 It provides interfaces to build a client or worker, and access to the\
 administrative protocol. The design approach is to keep it simple, with a\
 relatively thin abstraction of the Gearman protocol itself. It should be\

I can run rpminspect on each the "before build" and "after build" w/o issue but when used together it segfault.

I'm able to run it on other packages w/o issue like:

➜  python-gear git:(master) ✗ rpminspect -vk -f python-gunicorn-19.9.0-5.fc32                           
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/5.fc32/noarch/python-gunicorn-doc-19.9.0-5.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/5.fc32/noarch/python3-gunicorn-19.9.0-5.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/5.fc32/src/python-gunicorn-19.9.0-5.fc32.src.rpm...

Keeping working directory: /var/tmp/rpminspect/python-gunicorn-19.9.0-5.fc32
➜  python-gear git:(master) ✗ rpminspect -vk -f python-gunicorn-19.9.0-6.fc32
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/noarch/python3-gunicorn-19.9.0-6.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/noarch/python-gunicorn-doc-19.9.0-6.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/src/python-gunicorn-19.9.0-6.fc32.src.rpm...

➜  python-gear git:(master) ✗ rpminspect -vk /var/tmp/rpminspect/python-gunicorn-19.9.0-5.fc32/noarch/python3-gunicorn-19.9.0-5.fc32.noarch.rpm /var/tmp/rpminspect/python-gunicorn-19.9.0-6.fc32/noarch/python3-gunicorn-19.9.0-6.fc32.noarch.rpm
license:
--------
1) Valid License Tag in python3-gunicorn-19.9.0-6.fc32.noarch: MIT 
Result: INFO
Waiver Authorization: Not Waivable
Result: OK
...

The rpm I've built via buildmock is available here:
curl -kOL https://38.145.32.151/python3-gear-0.14.0-6.fc32.noarch.rpm

Thanks in advance for your help.
Fabien
@morucci
Copy link
Contributor Author

morucci commented Sep 13, 2019

Another try, I've build another package locally with fedpkg mockbuild (python-gunicorn) and tried to run:

➜  zuul-distro-jobs git:(master) ✗ rpminspect -v -f python-gunicorn-19.9.0-6.fc32                                                                                                     
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/noarch/python3-gunicorn-19.9.0-6.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/noarch/python-gunicorn-doc-19.9.0-6.fc32.noarch.rpm...
Downloading https://kojipkgs.fedoraproject.org/packages/python-gunicorn/19.9.0/6.fc32/src/python-gunicorn-19.9.0-6.fc32.src.rpm...

Keeping working directory: /var/tmp/rpminspect/python-gunicorn-19.9.0-6.fc32
➜  zuul-distro-jobs git:(master) ✗ rpminspect /var/tmp/rpminspect/python-gunicorn-19.9.0-6.fc32/noarch/python-gunicorn-doc-19.9.0-6.fc32.noarch.rpm /home/fabien/git/src.fedoraproject.org/python-gunicorn/results_python-gunicorn/19.9.0/7.fc32/python-gunicorn-doc-19.9.0-7.fc32.noarch.rpm
[1]    10914 segmentation fault (core dumped)  rpminspect

@dcantrell
Copy link
Collaborator

This is a really good find, totally a legit bug. I was able to quickly track down what was happening. In the metadata inspection, I compare the RPM name, vendor, license, and so on. Since you were comparing a Koji build package to a local build package, you did not have a Vendor tag in the locally built one. librpm was giving me NULL back when I asked for the header tag, and then I passed it to strcmp() and SIGSEGV.

So I have expanded that test to see if the Vendor tag is NULL or not and report accordingly. You can have gained, lost, or modified the Vendor tag now.

dcantrell added a commit that referenced this issue Sep 13, 2019
@dcantrell
In the 'metadata' inspection, do not assume the Vendor tag is set. (#43)
203cc19 
The Vendor tag may or may not be set depending on where you build a
package.  For packages built in the Fedora build system, they always get
a Vendor tag.  But if you build something locally, you probably don't
have a Vendor tag.  Account for this appropriately in the 'metadata'
inspection.

Also switch from using headerGetAsString() to headerGetString() to avoid
unnecessary memory allocation and leaking.
jeremycline pushed a commit to jeremycline/rpminspect that referenced this issue Jul 13, 2020
@dcantrell
In the 'metadata' inspection, do not assume the Vendor tag is set. (r…
5ac951d 
…pminspect#43)

The Vendor tag may or may not be set depending on where you build a
package.  For packages built in the Fedora build system, they always get
a Vendor tag.  But if you build something locally, you probably don't
have a Vendor tag.  Account for this appropriately in the 'metadata'
inspection.

Also switch from using headerGetAsString() to headerGetString() to avoid
unnecessary memory allocation and leaking.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dcantrell @morucci