severity 622084 normal
forwarded 622084 bind9-b...@isc.org
tags 622084 + upstream patch
thanks
[ bind9-bugs mailing list CC'ed. In the following, I'll provide a short
summary of the issue, full Debian bug report can be found at
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622084>. ]
Hi!
Since I've been hit by this issue as well, I decided to hunt I down, and
I'm fairly confident I've isolated it and found a fix. First of all,
here's what happens with both the bind9 version currently in Debian sid
(1:9.7.3.dfsg-1+b1), as well as current upstream release (9.8.0-P2).
So, the symptom is that nsupdate crashes upon exit when given a SIG(0)
keyfile, even when there is nothing to do:
% nsupdate -v -k some.key < /dev/null
mem.c:1099: INSIST(ctx->stats[i].gets == 0U) failed, back trace
#0 0x7fa892bb39d6 in ??
#1 0x7fa892bb393a in ??
#2 0x7fa892bc4ab7 in ??
#3 0x7fa892bc51dc in ??
#4 0x7fa8946ef467 in ??
#5 0x7fa8920c8ead in ??
#6 0x7fa8946e8ce9 in ??
zsh: abort /usr/bin/nsupdate -v -k < /dev/null
While nsupdate otherwise works fine, as this (a) causes an abnormal exit
code (thus potentially breaking scripts) and (b) core dumps depending on
the ulimits, I decided to raise the severity of the Debian bug to
"normal".
Upon investation, this seems to be caused by a memory leak in
setup_keyfile() detected upon program exit (at which point the assertion
triggers). The attached patch, dropping the reference count of the key
after adding it to the global variable `sig0key' fixes the issue for me.
The patch is against 9.8.0-P2, but I think it should apply to earlier
versions as well, or be most trivially backported.
--- bind-9.8.0-P2/bin/nsupdate/nsupdate.c 2011-01-10 06:32:03.000000000 +0100
+++ bind-9.8.0-P2.fixed/bin/nsupdate/nsupdate.c 2011-06-02 15:40:59.639453426 +0200
@@ -695,8 +695,10 @@
keyfile, isc_result_totext(result));
return;
}
- } else
+ } else {
dst_key_attach(dstkey, &sig0key);
+ dst_key_free(&dstkey);
+ }
}
static void
PS: Kudos to the bind9 developers for having such a stringent,
hard-enforced memory policy, and also providing the tools to track
such issues down -- nsupdate's "-M" option has been quite useful to
me here!
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
