Bug 1900536

Summary: [NMCI] NetworkManager build with assertions crashes with dracut network-legacy module
Product: Red Hat Enterprise Linux 8 Reporter: Filip Pokryvka <fpokryvk>
Component: NetworkManagerAssignee: Thomas Haller <thaller>
Status: CLOSED ERRATA QA Contact: Filip Pokryvka <fpokryvk>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: acardace, atragler, bgalvani, lrintel, rkhan, sukulkar, thaller, till, vbenes
Target Milestone: rcKeywords: Triaged
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 13:29:43 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:
Attachments:
Description Flags
reproducer by bgalvani@redhat.com none

Description Filip Pokryvka 2020-11-23 10:14:20 UTC
Created attachment 1732431 [details]
reproducer by bgalvani

Description of problem:
When Networkmanager is built with assertions, there is a crash when NetworkManager is starting after setup done by network-legacy dracut module.

Version-Release number of selected component (if applicable):
nm-1-26 branch (maybe even sooner)

How reproducible:
when NetworkManager is built with assertions

Steps to Reproduce:
run corresponfing NetworkManager-ci test: dracut_legacy_iSCSI_ibft_table
or run attached reproducer

Actual results:
NetworkManager crashes (Segmentation Fault)

Expected results:
There should be no crash.

Comment 1 Thomas Haller 2020-11-23 11:34:14 UTC
Hi,

Even as you attached a reproducer, could you still attach the stack-trace (or other useful infromation, if any)? Thanks.

Without it, it requires somebody looking at the bug to reproduce it -- which takes several minutes at best. In the worst case, the reproducer might not work for some reasons...

Presumably, you tested the reproducer, so it should be almost no effort to attach the information which you already have(??).

If it requires unreasonable effort of you to get more information, you are welcome to say so and don't provide it. But then at least say: "I cannot get a stack trace because XYZ", so you won't be asked for a stack trace.

Thanks!!

Comment 2 Beniamino Galvani 2020-11-23 12:21:15 UTC
Hi, this is the backtrace I get on master:

<info>  [1606133820.6775] manager: (enp8s0): assume: taking over an initramfs-configured connection
**
libnm:ERROR:../libnm-core/nm-connection.c:1797:_nmtst_connection_unchanging_changed_cb: code should not be reached
Bail out! libnm:ERROR:../libnm-core/nm-connection.c:1797:_nmtst_connection_unchanging_changed_cb: code should not be reached

Thread 1 "NetworkManager" received signal SIGABRT, Aborted.
0x00007ffff77039e5 in raise () from /lib64/libc.so.6
(gdb) backtrace 
#0  0x00007ffff77039e5 in raise () at /lib64/libc.so.6
#1  0x00007ffff76ec895 in abort () at /lib64/libc.so.6
#2  0x00007ffff7c7db6c in g_assertion_message_expr.cold () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7cdb9ff in g_assertion_message_expr () at /lib64/libglib-2.0.so.0
#4  0x00000000006ae97f in _nmtst_connection_unchanging_changed_cb (connection=<optimized out>, user_data=<optimized out>) at ../libnm-core/nm-connection.c:1797
#5  0x00007ffff7d9e88a in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#6  0x00007ffff7db1423 in signal_emit_unlocked_R.isra.0 () at /lib64/libgobject-2.0.so.0
#7  0x00007ffff7db7af9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#8  0x00007ffff7db7c63 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#9  0x00000000006af2fc in nm_connection_add_setting (connection=0x7fffdc001440, setting=setting@entry=0x96dd60) at ../libnm-core/nm-connection.c:139
#10 0x0000000000477f0a in recheck_assume_connection (self=self@entry=0x8fe020, device=device@entry=0x9c6a60) at ../src/nm-manager.c:2852
#11 0x00000000004784d4 in _device_realize_finish (self=self@entry=0x8fe020, device=device@entry=0x9c6a60, plink=plink@entry=0x8ae3a8) at ../src/nm-manager.c:3149
#12 0x000000000047bb6e in platform_link_added (self=self@entry=0x8fe020, ifindex=<optimized out>, plink=plink@entry=0x8ae3a8, guess_assume=1, dev_state=<optimized out>)
    at ../src/nm-manager.c:3466
#13 0x000000000047cae3 in platform_query_devices (self=self@entry=0x8fe020) at ../src/nm-manager.c:3574
#14 0x00000000004811b4 in nm_manager_start (self=self@entry=0x8fe020, error=error@entry=0x7fffffffd9c8) at ../src/nm-manager.c:6740
#15 0x00000000004216da in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:431

Comment 11 errata-xmlrpc 2021-05-18 13:29:43 UTC
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 (Moderate: NetworkManager and libnma security, 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/RHSA-2021:1574