Bug 2052872 - abrt failed to create coredump
Summary: abrt failed to create coredump
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Srb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
: 2050693 (view as bug list)
Depends On:
Blocks: F36BetaFreezeException F36FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-02-10 08:45 UTC by lnie
Modified: 2022-03-17 01:38 UTC (History)
14 users (show)

Fixed In Version: abrt-2.15.1-1.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-17 01:38:53 UTC
Type: Bug


Attachments (Terms of Use)
journal (416.71 KB, text/plain)
2022-02-10 08:45 UTC, lnie
no flags Details
ccpp tar (6.43 KB, application/gzip)
2022-02-10 08:48 UTC, lnie
no flags Details
screenshot (88.72 KB, image/png)
2022-02-10 08:49 UTC, lnie
no flags Details

Description lnie 2022-02-10 08:45:44 UTC
Created attachment 1860289 [details]
journal

Description of problem:
the coredump file abrt generated is empty,as a result,non-kernel crash can not be reported by gnome-abrt(screenshot).
I see a spice-vdagent crash after boot the newly installed system,but I'm not able to report it with gnome-abrt.
I also checked with "sleep 500 & pkill -SEGV sleep"

Version-Release number of selected component (if applicable):
abrt-2.15.0-3.fc36

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 lnie 2022-02-10 08:48:15 UTC
Created attachment 1860290 [details]
ccpp tar

Comment 2 lnie 2022-02-10 08:49:55 UTC
Created attachment 1860291 [details]
screenshot

Comment 3 Fedora Blocker Bugs Application 2022-02-10 09:06:02 UTC
Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because:

 This is a violation of the criteria:
All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test

Comment 4 lnie 2022-02-10 10:03:02 UTC
coredump is generated if you downgrade abrt to abrt-2.14.6-9.fc36,but you will see #2052914,as a result,gnome-abrt will not able to report non-kernel crash

Comment 5 Matej Grabovsky 2022-02-10 10:25:30 UTC
I can confirm this is indeed reproducible on Fedora 36.

@Michal: This might have something to do with the recent coredump-related changes in abrt.
Do you think you could double-check for any flukes?

Comment 6 Michal Srb 2022-02-10 11:16:47 UTC
We discussed this briefly yesterday. The problem is very likely related to the abrt+coredumpctl optimization change. I will test it.

Comment 7 Geoffrey Marr 2022-02-14 19:27:46 UTC
Discussed during the 2022-02-14 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test".

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-14/f36-blocker-review.2022-02-14-17.01.txt

Comment 8 Yann Droneaud 2022-02-28 14:13:28 UTC
This is a duplicate of bug #2050693

Comment 9 Michal Srb 2022-03-02 11:56:17 UTC
Michal Fabik found out that SELinux prevents abrt+coredumpctl to open+read the coredump file. I tried disabling SELinux just to test that this is indeed what's happening here and Michal was right:


######################################################################################################################

SELinux is preventing coredumpctl from read access on the file core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that coredumpctl should be allowed read access on the core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'coredumpctl' --raw | audit2allow -M my-coredumpctl
# semodule -X 300 -i my-coredumpctl.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_coredump_var_lib_t:s0
Target Objects                core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4
                              246.1646221121000000.zst [ file ]
Source                        coredumpctl
Source Path                   coredumpctl
Port                          <Unknown>
Host                          localhost-live
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-36.3-1.fc36.noarch
Local Policy RPM              selinux-policy-targeted-36.3-1.fc36.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost-live
Platform                      Linux localhost-live 5.17.0-0.rc5.102.fc36.x86_64
                              #1 SMP PREEMPT Mon Feb 21 19:16:16 UTC 2022 x86_64
                              x86_64
Alert Count                   3
First Seen                    2022-03-02 12:25:17 CET
Last Seen                     2022-03-02 12:38:42 CET
Local ID                      f1e93def-ce03-4c0c-b91f-8a6d369961fa

Raw Audit Messages
type=AVC msg=audit(1646221122.16:441): avc:  denied  { read } for  pid=4288 comm="coredumpctl" name="core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst" dev="vda2" ino=187869 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_coredump_var_lib_t:s0 tclass=file permissive=0


Hash: coredumpctl,abrt_t,systemd_coredump_var_lib_t,file,read

######################################################################################################################


However, the fact that coredump is being copied from coredumpctl to abrt problem directory immediately after the crash happens kind of beats the purpose of the optimization patch in abrt. Even if we fix the SELinux issue, we still end up in a situation when there are multiple copies of the same coredump on the filesystem, and not just when abrt needs the copy.

Comment 10 Michal Srb 2022-03-02 11:57:08 UTC
*** Bug 2050693 has been marked as a duplicate of this bug. ***

Comment 11 Fedora Update System 2022-03-10 21:14:51 UTC
FEDORA-2022-6d711f0d87 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d711f0d87

Comment 12 lnie 2022-03-11 03:04:36 UTC
This bug seems fixed,but I'm still not able to report bug using gnome-abrt,due to #2052914

Comment 13 Fedora Update System 2022-03-11 19:26:04 UTC
FEDORA-2022-6d711f0d87 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-6d711f0d87`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d711f0d87

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

Comment 14 Adam Williamson 2022-03-15 15:47:27 UTC
Also proposing this as Beta FE, we should fix this for Beta if we can so people can report crashes during live sessions and first boots.

Comment 15 Adam Williamson 2022-03-16 21:29:40 UTC
+6 Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/604 , marking accepted.

Comment 16 Fedora Update System 2022-03-17 01:38:53 UTC
FEDORA-2022-6d711f0d87 has been pushed to the Fedora 36 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.