Bug 1257841

Created attachment 1067928 [details]
File: backtrace

Created attachment 1067929 [details]
File: cgroup

Created attachment 1067930 [details]
File: core_backtrace

Created attachment 1067931 [details]
File: dso_list

Created attachment 1067932 [details]
File: environ

Created attachment 1067933 [details]
File: limits

Created attachment 1067934 [details]
File: machineid

Created attachment 1067935 [details]
File: maps

Created attachment 1067936 [details]
File: open_fds

Created attachment 1067937 [details]
File: proc_pid_status

Created attachment 1067938 [details]
File: var_log_messages

I suspect this is related to https://bugzilla.redhat.com/show_bug.cgi?id=1247721 (and possibly fixed by same commit) but I'm not sure how it would haved caused a segfault. 

But... in the core_backtrace, there is also code in a different python context that is doing name resolution stuff.

ie:

           [ {   "address": 139631890442159
                ,   "build_id": "b0a1dfa62c6af7aa62487e3c260dc4b9c24d8bf8"
                ,   "build_id_offset": 1013679
                ,   "function_name": "__sendmmsg"
                ,   "file_name": "/lib64/libc.so.6"
                }
              , {   "address": 139631732344628
                ,   "build_id": "d08cf135d143704da93e5f025ae6ae6943838f03"
                ,   "build_id_offset": 46900
                ,   "function_name": "__libc_res_nsend"
                ,   "file_name": "/lib64/libresolv.so.2"
                }
              , {   "address": 139631732333735
                ,   "build_id": "d08cf135d143704da93e5f025ae6ae6943838f03"
                ,   "build_id_offset": 36007
                ,   "function_name": "__libc_res_nquery"
                ,   "file_name": "/lib64/libresolv.so.2"
                }
              , {   "address": 139631732336719
                ,   "build_id": "d08cf135d143704da93e5f025ae6ae6943838f03"
                ,   "build_id_offset": 38991
                ,   "function_name": "__libc_res_nsearch"
                ,   "file_name": "/lib64/libresolv.so.2"
                }
              , {   "address": 139631425178573
                ,   "build_id": "16fec8791a1ad2137e47effd8e110201f12ceb97"
                ,   "build_id_offset": 11213
                ,   "function_name": "_nss_dns_gethostbyname4_r"
                ,   "file_name": "/lib64/libnss_dns.so.2"
                }
              , {   "address": 139631890329832
                ,   "build_id": "b0a1dfa62c6af7aa62487e3c260dc4b9c24d8bf8"
                ,   "build_id_offset": 901352
                ,   "function_name": "gaih_inet"
                ,   "file_name": "/lib64/libc.so.6"
                }
              , {   "address": 139631890343853
                ,   "build_id": "b0a1dfa62c6af7aa62487e3c260dc4b9c24d8bf8"
                ,   "build_id_offset": 915373
                ,   "function_name": "getaddrinfo"
                ,   "file_name": "/lib64/libc.so.6"
                }
              , {   "address": 139631567861261
                ,   "build_id": "c61e79517deb9894892e057c5587a2dd0317038d"
                ,   "build_id_offset": 26125
                ,   "function_name": "socket_getaddrinfo"
                ,   "file_name": "/usr/lib64/python2.7/lib-dynload/_socketmodule.so"
                }


Which seems harmless, but registration does some strange name resolver klugery.
ie, registergui.py:reset_resolver() that uses ctypes to call glibcs __res_init().

Is /var/log/rhsm/rhsm.log from this machine available? If so, check if there is a "reset_resolver failed:" warning in the logs.

Hard to say if that could cause the segfault, but given resolver hackery, threads, event loop, etc I suspect it's related.

(In reply to Adrian Likins from comment #13)
> I suspect this is related to
> https://bugzilla.redhat.com/show_bug.cgi?id=1247721 (and possibly fixed by
> same commit) but I'm not sure how it would haved caused a segfault. 

> Hard to say if that could cause the segfault, but given resolver hackery,
> threads, event loop, etc I suspect it's related.

Hmm, nm. Not a segfault, but a SIGABRT, which seems to come from

gtk+/gtk/gtkprogressbar.c in tick_cb:

g_assert (priv->pulse2 > priv->pulse1);

Which seems more likely to be caused by the issue fixed with https://bugzilla.redhat.com/show_bug.cgi?id=1247721

as suggested by alikins in comment 14, the fix in https://bugzilla.redhat.com/show_bug.cgi?id=1247721#c4 was a likely fix for this bug too.  Please re-test with subscription-manager-gui-1.15.9-8.el7 or newer

I am NOT able to reproduce the crash in comment 0 with RHEL-7.2-Snapshot-2.1 version....

[root@jsefler-rhel72-snap21 ~]# subscription-manager version
server type: This system is currently not registered.
subscription management server: 0.9.51.5-1
subscription management rules: 5.15
subscription-manager: 1.15.9-10.el7
python-rhsm: 1.15.4-5.el7

Closing this issue as test was not able to duplicate it in RHEL-7.2-Snapshot-2.1

I tried to reproduce the crash with subscription-manager-gui-1.15.9-13.el7 and everything seems to work fine now. Thank you!