Bug 998937
Summary: | [abrt] ypbind-1.37.1-3.fc19: __netlink_free_handle: Process /usr/sbin/ypbind was killed by signal 6 (SIGABRT) | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Edgar Hoch <edgar.hoch> | ||||||||||||||||||||||||
Component: | ypbind | Assignee: | Matej Mužila <mmuzila> | ||||||||||||||||||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||
Version: | 19 | CC: | edgar.hoch, hhorak | ||||||||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||
Whiteboard: | abrt_hash:67ce037c2643bf90d5c91fa33e54fca5e96069f8 | ||||||||||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||||
Last Closed: | 2015-02-17 16:50:43 UTC | Type: | --- | ||||||||||||||||||||||||
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
Edgar Hoch
2013-08-20 11:34:45 UTC
Created attachment 788442 [details]
File: backtrace
Created attachment 788443 [details]
File: cgroup
Created attachment 788444 [details]
File: core_backtrace
Created attachment 788445 [details]
File: dso_list
Created attachment 788446 [details]
File: environ
Created attachment 788447 [details]
File: limits
Created attachment 788448 [details]
File: maps
Created attachment 788449 [details]
File: open_fds
Created attachment 788450 [details]
File: proc_pid_status
Created attachment 788451 [details]
File: var_log_messages
Thank you for the report, but I don't see ypbind doing anything wrong. Is that failure reproducible? If it happened only once, I'd say it could be caused by some unspecified memory problem. The failure was reproducible. It occurs after each reboot of a fresh installed system (yesterday, with kickstart). /var/log/messages contains lines like this: Aug 20 13:47:04 myhost ypbind[819]: *** Error in `/usr/sbin/ypbind': corrupted double-linked list: 0x00007fcd3934c310 *** Aug 20 13:47:04 myhost ypbind[819]: *** Error in `/usr/sbin/ypbind': corrupted double-linked list: 0x00007fcd3934c350 *** When I have started ypbind by hand (systemctl restart ypbind), then it works as expected, no crash. In the meentime I found that firewalld.service was disabled. I had a line "firewall --disable" in my kickstart file, but this line was ignored in the last weeks by kickstart / anaconda. It seems that something has changed - it is fine that the kickstart option is honored now. Now I have enabled firewalld.service manually and rebooted the host again - two times. Now - with firewalld.service enabled - ypbind starts and don't crash and works fine. So this is ok for me, you may close the bug. But I am wondering about the message about the corrupted double-linked list. ypbind got a timeout, it founds no nis servers, if firewalld was disabled. Now I tried it again to reboot with firewalld disabled. Now ypbind crashes again: Aug 20 14:50:50 myhost ypbind[818]: *** Error in `/usr/sbin/ypbind': free(): invalid next size (normal): 0x00007f8d146c0260 *** ... If I enable firewalld again then ypbind does not crash. So it is reproducible. (In reply to Edgar Hoch from comment #12) > The failure was reproducible. It occurs after each reboot of a fresh > installed system (yesterday, with kickstart). /var/log/messages contains > lines like this: > > Aug 20 13:47:04 myhost ypbind[819]: *** Error in `/usr/sbin/ypbind': > corrupted double-linked list: 0x00007fcd3934c310 *** > Aug 20 13:47:04 myhost ypbind[819]: *** Error in `/usr/sbin/ypbind': > corrupted double-linked list: 0x00007fcd3934c350 *** Memory corruption again, but a bit different message this time, so I'd wonder if the backtrace looks the same or not. > When I have started ypbind by hand (systemctl restart ypbind), then it works > as expected, no crash. But this time the firewall was fixed and ypbind was able to connect to YP servers, right? > But I am wondering about the message about the corrupted double-linked list. > ypbind got a timeout, it founds no nis servers, if firewalld was disabled. In this case a SIGTERM is sent to ypbind, which is how the daemon was always turned off, so it shouldn't be the problem. > Now I tried it again to reboot with firewalld disabled. Now ypbind crashes > again: > > Aug 20 14:50:50 myhost ypbind[818]: *** Error in `/usr/sbin/ypbind': free(): > invalid next size (normal): 0x00007f8d146c0260 *** Again a different message. Was the firewall fixed this time so ypbind was able to connect to YP servers? > If I enable firewalld again then ypbind does not crash. > So it is reproducible. I see some changes in relevant part of code in glibc, especially the following chunk seems suspicious to me, since enabling strict-aliasing could make problem in some memory operations. But it's just a guess: diff -rup glibc-2.16-75f0d304/sunrpc/Makefile glibc-2.18/sunrpc/Makefile --- glibc-2.16-75f0d304/sunrpc/Makefile 2013-08-20 15:21:08.131164559 +0200 +++ glibc-2.18/sunrpc/Makefile 2013-08-11 00:52:55.000000000 +0200 @@ -150,10 +150,6 @@ sunrpc-CPPFLAGS = -D_RPC_THREAD_SAFE_ CPPFLAGS += $(sunrpc-CPPFLAGS) BUILD_CPPFLAGS += $(sunrpc-CPPFLAGS) -CFLAGS-clnt_tcp.c += -fno-strict-aliasing -CFLAGS-clnt_udp.c += -fno-strict-aliasing -CFLAGS-clnt_unix.c += -fno-strict-aliasing - $(objpfx)tst-getmyaddr: $(common-objpfx)linkobj/libc.so $(objpfx)tst-xdrmem: $(common-objpfx)linkobj/libc.so $(objpfx)tst-xdrmem2: $(common-objpfx)linkobj/libc.so Created attachment 788605 [details]
Lines with ypbind from /var/log/messages
I attached an extract of /var/log/messages with the lines containing ypbind. I hope this helps.
(In reply to Honza Horak from comment #13) > But this time the firewall was fixed and ypbind was able to connect to YP > servers, right? I only have enabled the firewall (systemctl enable firewalld) and have rebooted. The network interface is configured to zone "work". > > But I am wondering about the message about the corrupted double-linked list. > > ypbind got a timeout, it founds no nis servers, if firewalld was disabled. > > In this case a SIGTERM is sent to ypbind, which is how the daemon was always > turned off, so it shouldn't be the problem. > > > Now I tried it again to reboot with firewalld disabled. Now ypbind crashes > > again: > > > > Aug 20 14:50:50 myhost ypbind[818]: *** Error in `/usr/sbin/ypbind': free(): > > invalid next size (normal): 0x00007f8d146c0260 *** > > Again a different message. Was the firewall fixed this time so ypbind was > able to connect to YP servers? I have disableed the firewall this time. For testing, I have enabled the firewall and rebooted, disabled the firewall and rebooted, enabled again... Thank you for your feedback and also bug #999121 reported. It is weird that the daemon crashes in different places and with different signals. What seems clear that something is terribly wrong with memory. But it's not clear to me if it is in ypbind/glibc/kernel or it can be some more general problem (memory physically damaged). I understand that the bug could have been there for some time already and just didn't show up because the firewalld was enabled. But still, it could give some clue if you would be able to downgrade ypbind, glibc and eventually kernel to some of the older builds and see if it helps. Otherwise I don't have any concrete idea where to start. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |