Bug 984687 - [abrt] bind-utils-9.9.3-3.P1.fc19: isc_assertion_failed: Process /usr/bin/nsupdate was killed by signal 6 (SIGABRT)
Summary: [abrt] bind-utils-9.9.3-3.P1.fc19: isc_assertion_failed: Process /usr/bin/nsu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Hozza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:f3bdf92911f0eb6581e1b1f993f...
: 1017077 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-15 16:59 UTC by Stef Walter
Modified: 2014-10-14 13:45 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-01-20 11:03:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (6.19 KB, text/plain)
2013-07-15 17:00 UTC, Stef Walter
no flags Details
File: cgroup (154 bytes, text/plain)
2013-07-15 17:00 UTC, Stef Walter
no flags Details
File: core_backtrace (688 bytes, text/plain)
2013-07-15 17:00 UTC, Stef Walter
no flags Details
File: dso_list (2.55 KB, text/plain)
2013-07-15 17:01 UTC, Stef Walter
no flags Details
File: environ (303 bytes, text/plain)
2013-07-15 17:01 UTC, Stef Walter
no flags Details
File: limits (1.29 KB, text/plain)
2013-07-15 17:01 UTC, Stef Walter
no flags Details
File: maps (13.03 KB, text/plain)
2013-07-15 17:01 UTC, Stef Walter
no flags Details
File: open_fds (102 bytes, text/plain)
2013-07-15 17:01 UTC, Stef Walter
no flags Details
File: proc_pid_status (893 bytes, text/plain)
2013-07-15 17:02 UTC, Stef Walter
no flags Details

Description Stef Walter 2013-07-15 16:59:59 UTC
Description of problem:
Crashed while running ipa-client-install.

Version-Release number of selected component:
bind-utils-9.9.3-3.P1.fc19

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        /usr/bin/nsupdate -g
crash_function: isc_assertion_failed
executable:     /usr/bin/nsupdate
kernel:         3.9.9-301.fc19.x86_64
runlevel:       N 5
uid:            0
var_log_messages: Jul 15 17:31:00 stef abrt[23778]: Saved core dump of pid 23691 (/usr/bin/nsupdate) to /var/tmp/abrt/ccpp-2013-07-15-17:31:00-23691 (44204032 bytes)

Truncated backtrace:
Thread no. 1 (4 frames)
 #2 isc_assertion_failed at assertions.c:58
 #3 destroy at mem.c:1102
 #4 isc__mem_destroy at mem.c:1253
 #5 cleanup at ./nsupdate.c:2961

Comment 1 Stef Walter 2013-07-15 17:00:09 UTC
Created attachment 773825 [details]
File: backtrace

Comment 2 Stef Walter 2013-07-15 17:00:15 UTC
Created attachment 773826 [details]
File: cgroup

Comment 3 Stef Walter 2013-07-15 17:00:23 UTC
Created attachment 773827 [details]
File: core_backtrace

Comment 4 Stef Walter 2013-07-15 17:01:33 UTC
Created attachment 773828 [details]
File: dso_list

Comment 5 Stef Walter 2013-07-15 17:01:37 UTC
Created attachment 773829 [details]
File: environ

Comment 6 Stef Walter 2013-07-15 17:01:42 UTC
Created attachment 773830 [details]
File: limits

Comment 7 Stef Walter 2013-07-15 17:01:46 UTC
Created attachment 773831 [details]
File: maps

Comment 8 Stef Walter 2013-07-15 17:01:57 UTC
Created attachment 773832 [details]
File: open_fds

Comment 9 Stef Walter 2013-07-15 17:02:01 UTC
Created attachment 773833 [details]
File: proc_pid_status

Comment 10 Tomáš Hozza 2013-10-18 15:25:27 UTC
*** Bug 1017077 has been marked as a duplicate of this bug. ***

Comment 11 Tomáš Hozza 2013-10-18 15:26:14 UTC
Hi.

Can you please describe what were you doing when nslookup crashed? So I can
reproduce it.

Thanks!

Comment 12 Stef Walter 2013-10-18 19:12:03 UTC
I wasn't using nslookup directly. It was invoked by sssd.

Comment 13 Tomáš Hozza 2013-10-22 07:03:45 UTC
(In reply to Stef Walter from comment #12)
> I wasn't using nslookup directly. It was invoked by sssd.

Did it happen only once, or does it crash every time it is invoked by sssd?

Comment 14 Tomáš Hozza 2013-10-22 07:04:41 UTC
Also if you have some steps I can follow to reproduce this issue, it would be
more than helpful.

Thanks.

Comment 15 Tomáš Hozza 2013-11-27 15:11:02 UTC
I believe this issue is the same as Bug #1034824

Comment 16 Tomáš Hozza 2013-11-27 15:39:47 UTC
Upstream Bug [ISC-Bugs #35073]

Comment 17 Tomáš Hozza 2013-11-28 10:17:12 UTC
Fixed in:
bind-9.9.3-13.P2.fc19
bind-9.9.4-9.fc20
bind-9.9.4-9.fc21

Comment 18 Fedora Update System 2014-01-14 13:39:23 UTC
bind-9.9.3-14.P2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/bind-9.9.3-14.P2.fc19

Comment 19 Fedora Update System 2014-01-14 13:48:37 UTC
bind-9.9.4-11.P2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/bind-9.9.4-11.P2.fc20

Comment 20 Fedora Update System 2014-01-18 04:21:39 UTC
bind-9.9.3-14.P2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2014-01-18 04:24:38 UTC
bind-9.9.4-11.P2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Scott Poore 2014-10-14 12:56:36 UTC
Was this fix applied to RHEL6 at some point also?  I believe I saw this on a RHEL6.6 test.  Unfortunately, we haven't seen it more than once so I can't speak to how easy to reproduce.

Should I open a separate bug for RHEL6 for this?  Or is this the same and should be cloned?

:[New Thread 7007]
:[Thread debugging using libthread_db enabled]
:Core was generated by `/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt'.
rogram terminated with signal 6, Aborted.
:#0  0x00a5b424 in __kernel_vsyscall ()
:
:Thread 1 (Thread 0xb7784950 (LWP 7007)):
:#0  0x00a5b424 in __kernel_vsyscall ()
:No symbol table info available.
:#1  0x00d49871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
:        resultvar = <value optimized out>
:        resultvar = <value optimized out>
:        pid = 15405044
:        selftid = 7007
:#2  0x00d4b14a in abort () at abort.c:92
:        save_stage = 2
:        act = {__sigaction_handler = {sa_handler = 0xbfd55854, sa_sigaction = 0xbfd55854}, sa_mask = {__val = {7374056, 3218430024, 5384788, 0, 3078122816, 5, 0, 1, 3078133784, 3218430056, 5384788, 0, 0, 5, 0, 1, 3078133784, 0, 3218430096, 3078121384, 3218430024, 3218430036, 25, 5384440, 3078133784, 0, 3218430128, 7386462, 3218430056, 3218430068, 134519818, 7386232}}, sa_flags = -1216833512, sa_restorer = 0}
:        sigs = {__val = {32, 0 <repeats 31 times>}}
:#3  0x00711dd9 in isc_assertion_failed (file=0x750b24 "mem.c", line=1099, type=isc_assertiontype_insist, cond=0x750df6 "ctx->stats[i].gets == 0U") at assertions.c:58
:No locals.
:#4  0x007258db in destroy (ctx=<value optimized out>) at mem.c:1099
:        i = <value optimized out>
:        ondest = {magic = 3218430272, events = {head = 0x511a65, tail = 0x522ab0}}
:#5  0x00725bd5 in isc__mem_destroy (ctxp=0x80554e0) at mem.c:1250
:        ctx = 0x9ee1018
:#6  0x080525a1 in cleanup (argc=3, argv=0xbfd55a74) at ./nsupdate.c:2913
:No locals.
:#7  main (argc=3, argv=0xbfd55a74) at ./nsupdate.c:2965
:        result = <value optimized out>

Comment 23 Tomáš Hozza 2014-10-14 13:45:58 UTC
Hi Scott.

I don't think it was applied to RHEL-6. Feel free to clone this bug if able to reproduce e.g. with reproducer from Bug #1034824

Anyway the issue is caused by a memory leak in nsupdate.


Note You need to log in before you can comment on or make changes to this bug.