Bug 1891770
| Summary: | GUI Installation crashes with signal 6, free: invalid pointer() | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Radek Vykydal <rvykydal> | ||||||
| Component: | openscap | Assignee: | Jan Černý <jcerny> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Matus Marhefka <mmarhefk> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 8.4 | CC: | bbarve, boyang, bsanford, ekolesni, hhei, huzhao, jkonecny, jstodola, ldu, matyc, mhaicman, ribarry, spoore, wsato, xuli, yacao, yuxisun | ||||||
| Target Milestone: | rc | Keywords: | AutoVerified | ||||||
| Target Release: | 8.4 | Flags: | pm-rhel:
mirror+
|
||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | openscap-1.3.4-4.el8 | Doc Type: | No Doc Update | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-05-18 15:29:12 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1890092, 1897024 | ||||||||
| Attachments: |
|
||||||||
|
Description
Radek Vykydal
2020-10-27 10:24:27 UTC
Our lorax-packages.log shows this diff between working an non-working nightly kstests: tigervnc-server-minimal webkit2gtk3-jsc libselinux-utils webkit2gtk3 python3-libselinux tigervnc-license tigervnc-server-module openscap flatpak-libs openscap-python3 libselinux openscap-utils memtest86+ openscap-scanner -geoclue2 -avahi-glib -ModemManager-glib Created attachment 1726291 [details]
lorax-packages.log listing package versions in failing installer image
From the core dump: Stack trace of thread 2511: #0 0x00007f71b200080f raise (libc.so.6) #1 0x00007f71b1feac45 abort (libc.so.6) #2 0x00007f71b2043997 __libc_message (libc.so.6) #3 0x00007f71b204ad9c malloc_printerr (libc.so.6) #4 0x00007f71b204eaae free_check.part.4 (libc.so.6) #5 0x00007f718b501f7c SEXP_list_pop (libopenscap.so.25) #6 0x00007f718b4fd4c2 SEAP_packet_recv (libopenscap.so.25) #7 0x00007f718b4ff311 SEAP_recvmsg (libopenscap.so.25) #8 0x00007f718b4f6470 probe_input_handler (libopenscap.so.25) #9 0x00007f71b2b1e15a start_thread (libpthread.so.0) #10 0x00007f71b20c5f33 __clone (libc.so.6) The failure seems to be caused by libopenscap. The installation works, when I hide OSCAPSpoke, so reassigning to the OSCAP add-on. This seems to be causing a failure of rtt installer gating tests on today's anaconda build[1] : https://beaker.engineering.redhat.com/recipes/9026265#installation console.log: http://lab-02.rhts.eng.bos.redhat.com/beaker/logs/recipes/9026+/9026265/console.log Maybe we should add package with libopenscap to reverse depency gating for Anaconda? [1] https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1378789 Moving to OpenSCAP, as the installer just makes the library crash. *** Bug 1895090 has been marked as a duplicate of this bug. *** We confirm we can reproduce it on the latest RHEL 8 nightly as of 2020-11-09. We don't see any problem that is obvious. We suspect that it can be invalid usage of free(). There were some recent changes in memory, for example https://github.com/OpenSCAP/openscap/pull/1584/. We will investigate further. (In reply to Radek Vykydal from comment #7) > Maybe we should add package with libopenscap to reverse depency gating for > Anaconda? > > [1] https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1378789 Matej, it seems that some revdeps oscap-anaconda-addon tests are run for openscap package updates. But the issue was not revealed by the gating test? It seems to be a dirinstall run in graphical mode and this BZ is hit only in graphical mode so it might be caught by the test - but I am not sure if the problem appears also for dirinstall. Anaconda functional gating test (which is dirinstall in text mode) would not catch the issue anyway. I wonder if we could run anaconda rtt tier1 test as rev dependency then, and if it would make sense. Or should the oscap-anaconda-addon revdep test catch most of the problems. And this one ? (In reply to Radek Vykydal from comment #11) > (In reply to Radek Vykydal from comment #7) > > > Maybe we should add package with libopenscap to reverse depency gating for > > Anaconda? > > > > [1] https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1378789 > > Matej, it seems that some revdeps oscap-anaconda-addon tests are run for > openscap package updates. But the issue was not revealed by the gating test? > It seems to be a dirinstall run in graphical mode and this BZ is hit only in > graphical mode so it might be caught by the test - but I am not sure if the > problem appears also for dirinstall. Ah, so apparently it is text mode, same as in anaconda gating test. http://artifacts.osci.redhat.com/rhel-8.3.0-packages/rhel-revdep-pipeline/openscap/30851295/package-tests/oscap-anaconda-addon/logs/PASS-Sanity-dir-install.log The same traceback can be also simply reproduced outside of installation environment by setting MALLOC_CHECK_=2.
[jcerny@thinkpad ~]$ rpm -q openscap
openscap-1.3.4-2.fc32.x86_64
[jcerny@thinkpad ~]$ MALLOC_CHECK_=2 oscap xccdf eval /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
free(): invalid pointer
Aborted (core dumped)
[jcerny@thinkpad ~]$ MALLOC_CHECK_=2 gdb --args oscap xccdf eval /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
....
....
#0 0x00007ffff7cc69e5 in raise () from /usr/lib64/libc.so.6
#1 0x00007ffff7caf895 in abort () from /usr/lib64/libc.so.6
#2 0x00007ffff7d0a857 in __libc_message () from /usr/lib64/libc.so.6
#3 0x00007ffff7d11d7c in malloc_printerr () from /usr/lib64/libc.so.6
#4 0x00007ffff7d13fe2 in free_check () from /usr/lib64/libc.so.6
#5 0x00007ffff7f4dd0c in SEXP_list_pop (list=0x55555f890870) at /usr/src/debug/openscap-1.3.4-2.fc32.x86_64/src/OVAL/probes/SEAP/sexp-manip.c:1306
#6 0x00007ffff7f49192 in SEAP_packet_recv (ctx=<optimized out>, sd=<optimized out>, packet=0x7ffff57bfc38)
at /usr/src/debug/openscap-1.3.4-2.fc32.x86_64/src/OVAL/probes/SEAP/seap-packet.c:668
#7 0x00007ffff7f4b071 in SEAP_recvmsg (ctx=0x55555f88f7e0, sd=32, seap_msg=0x7ffff57bfcb8) at /usr/src/debug/openscap-1.3.4-2.fc32.x86_64/src/OVAL/probes/SEAP/seap.c:360
#8 0x00007ffff7f41e70 in probe_input_handler (arg=0x7ffff67c1c40) at /usr/src/debug/openscap-1.3.4-2.fc32.x86_64/src/OVAL/probes/probe/input_handler.c:102
#9 0x00007ffff7e5d432 in start_thread () from /usr/lib64/libpthread.so.0
#10 0x00007ffff7d8b913 in clone () from /usr/lib64/libc.so.6
(In reply to Radek Vykydal from comment #11) > (In reply to Radek Vykydal from comment #7) > > > Maybe we should add package with libopenscap to reverse depency gating for > > Anaconda? > > > > Matej, it seems that some revdeps oscap-anaconda-addon tests are run for > openscap package updates. But the issue was not revealed by the gating test? > It seems to be a dirinstall run in graphical mode and this BZ is hit only in > graphical mode so it might be caught by the test - but I am not sure if the > problem appears also for dirinstall. > > Anaconda functional gating test (which is dirinstall in text mode) would not > catch the issue anyway. > I wonder if we could run anaconda rtt tier1 test as rev dependency then, and > if it would make sense. > Or should the oscap-anaconda-addon revdep test catch most of the problems. > And this one ? > ... > Ah, so apparently it is text mode, same as in anaconda gating test. In this particular case, we will make sure that issues of this kind are caught by the openscap gating. It would be great to have automated OAA GUI tests as part of OAA gating though. A patch has been proposed to upstream by https://github.com/OpenSCAP/openscap/pull/1627. The patch https://github.com/OpenSCAP/openscap/pull/1627 has been accepted by upstream. *** Bug 1897131 has been marked as a duplicate of this bug. *** *** Bug 1893663 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openscap bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2021:1784 |