Sure, here is 9.18.26 with all the required patches:
https://ftp.isc.org/isc/bind9/9.18.34/bind-9.18.34.tar.xz
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 28. 2. 202
Hi Ondrej,
Thank you for your prompt response. We recently upgraded to this version as it
was marked as stable. It may take some time to upgrade to the latest version of
bind-9.18. Meanwhile i was wondering if i can patch the fix (if available) to
our current version or any workaround available
Start with upgrading to the latest 9.18. You are 8 versions behind, and yes,
bugs get fixed.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 27. 2. 2025, at 23:12, avije
Hi All,
I have bind9 version 9.18.26 deployed on a dns server running on the AWS
ECS cluster. I noticed "named" crashed with assertion failure. It has
happened a few times now.
>From the coredump, it appears named crashied when it is trying to respond
to a query. I was sending a d
[0x7fe1b4e4d50a]
> named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3]
> named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3]
> named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850]
> named[4787]: /lib/x86_64-linux-gnu/libc.so.6
) [0x7fe1b42b3ac3]
named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850]
named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850]
named[4787]: exiting (due to assertion failure)
named[4787]: exiting (due to assertion failure)
Please advise, I have checked online with
11 15:02:51 named[5567]: #9 0x713bcc081b60 in ??
May 11 15:02:51 nnnn named[5567]: exiting (due to assertion failure)
The first entry is assertion_failed(), but the rest I can't
manage to decode, even after doing "b main" and "r", and as far
as I can see there's no core f
> On 7 Mar 2019, at 9:36 pm, 徐明杰 wrote:
>
> Hello all, I have some questions about "Assertion Failure" in BIND.
> Most of the security advisories report that the security bugs can result in a
> assertion failure. I'm not familiar with event-driven programming
On Thu, Mar 07, 2019 at 06:36:09PM +0800, 徐明杰 wrote:
> Hello all, I have some questions about "Assertion Failure" in BIND. Most
> of the security advisories report that the security bugs can result in a
> assertion failure. I'm not familiar with event-driven programming
&g
Hello all, I have some questions about "Assertion Failure" in BIND.
Most of the security advisories report that the security bugs can result in a
assertion failure. I'm not familiar with event-driven programming paradigm, so
I' not sure if every assertion failure can cause
in BIND 9.12 can lead to an assertion failure in rbtdb.c, even
when stale-answer-enable is off. Additionally, problematic
interaction between the serve-stale feature and NSEC aggressive
negative caching can in some cases cause undesirable behavior
from named, such as a recursion loop
database reference counting can lead to an
assertion failure if a server which is running an affected version
of BIND attempts several transfers of a slave zone in quick
succession.
This defect could be deliberately exercised by an attacker who
is permitted to cause a vulnerable server
:32:28 ns1 named[1057]: exiting (due to assertion failure)
Is there any known bug triggering this behaviour ?
Thanks in advance.
Regards,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-us
-9.9.4-51.el7.x86_64 using bind-dyndb-ldap
in CentOS it triggering an assertion failure
I also want to add that SELinux is in permissive mode.
On 10/10/17 14:14, Radu Pantiru wrote:
I did request help with CentOS but my feeling is that you may be able
to give me some information what happens at
using bind-dyndb-ldap in CentOS it
triggering an assertion failure
I also want to add that SELinux is in permissive mode.
On 10/10/17 14:14, Radu Pantiru wrote:
I did request help with CentOS but my feeling is that you may be able to give
me some information what happens at the code level.
It is
I also want to add that SELinux is in permissive mode.
On 10/10/17 14:14, Radu Pantiru wrote:
I did request help with CentOS but my feeling is that you may be able
to give me some information what happens at the code level.
It is not happening every time when reloading the named-pkcs11 servi
6:24 host named[32115]: #3 0x7f4ae9f25d5b in ??
> Apr 19 20:46:24 host named[32115]: #4 0x7f4ae98d6064 in ??
> Apr 19 20:46:24 host named[32115]: #5 0x7f4ae92a462d in ??
> Apr 19 20:46:24 host named[32115]: exiting (due to assertion failure)
>
> ( Same log on Pastebin https://pas
??
> Apr 19 20:46:24 host named[32115]: #1 0x7f4ae9f038ea in ??
> Apr 19 20:46:24 host named[32115]: #2 0x7f4aeb5e914e in ??
> Apr 19 20:46:24 host named[32115]: #3 0x7f4ae9f25d5b in ??
> Apr 19 20:46:24 host named[32115]: #4 0x7f4ae98d6064 in ??
> Apr 19 20:46:24 host named[32115]: #5 0x7f4ae92a46
r 19 20:46:24 host named[32115]: #2 0x7f4aeb5e914e in ??
Apr 19 20:46:24 host named[32115]: #3 0x7f4ae9f25d5b in ??
Apr 19 20:46:24 host named[32115]: #4 0x7f4ae98d6064 in ??
Apr 19 20:46:24 host named[32115]: #5 0x7f4ae92a462d in ??
Apr 19 20:46:24 host named[32115]: exiting (due to assertion failur
> example.org and then used RPZ to create a CNAME for foo.example.com
> > pointing to foo.example.org
> >
> >
> > Anyway, with the NS records, I got an assertion failure:
> > 10-Jun-2016 15:49:58.584 client 10.10.207.244#49952 (foo.example.com
> > <http://sts.aust
; Anyway, with the NS records, I got an assertion failure:
> 10-Jun-2016 15:49:58.584 client 10.10.207.244#49952 (foo.example.com
> <http://sts.austinenergy.com/>): query: foo.example.com
> <http://sts.austinenergy.com/> IN A + (10.2.123.132)
> Jun 10 15:49:58 ns11 named[2248]
foo.example.com A
records. I should have created the glue in example.org and then used RPZ to
create a CNAME for foo.example.com pointing to foo.example.org
Anyway, with the NS records, I got an assertion failure:
10-Jun-2016 15:49:58.584 client 10.10.207.244#49952 (foo.example.com
<h
On Tue, May 03, 2016 at 10:41:10AM +1000, James Brown wrote:
> Upgraded to 9.10.4 a few days ago, and this morning it crashed:
Thanks. The best place to send bug reports is bind9-b...@isc.org,
not bind-users.
> Running Mac OS X 10.11.4.
>
> Have never had a problem with any previous version of B
in isc_thread_yield()+0x7ffe9af8258a
03-May-2016 04:04:22.873 #11 0x7fff9b195351 in isc_thread_yield()+0x7ffe9af7ffc1
03-May-2016 04:04:22.873 exiting (due to assertion failure)
Running Mac OS X 10.11.4.
Have never had a problem with any previous version of BIND.
Hopefully it’s a one-off. Let me know
7;
Just did another recompile as you said, What would the cause be?
Thinking of going back to some other version.
From: Wah Peng [mailto:wah_p...@yahoo.com.sg]
Sent: Monday, 12 October 2015 10:37 PM
To: Neil
Cc: bind-users@lists.isc.org
Subject: Re: BIND 9.9.8 Assertion Failure {R
0.1#53) 22/Invalid
> argument
> 12-Oct-2015 20:35:49.056 general: error: socket.c:5407: unexpected error:
> 12-Oct-2015 20:35:49.056 general: error: connect(0.0.0.1#53) 22/Invalid
> argument
> 12-Oct-2015 21:01:47.916 general: critical: resolver.c:1784:
> INSIST(fctx->referen
(0.0.0.1#53) 22/Invalid
argument
12-Oct-2015 21:01:47.916 general: critical: resolver.c:1784:
INSIST(fctx->references > 1) failed
12-Oct-2015 21:01:47.916 general: critical: exiting (due to assertion
failure)
Neil
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind
file descriptor
> exceeds limit (4096/4096)
>
> 02-Oct-2015 18:03:01.188 general: error: socket: file descriptor
> exceeds limit (4096/4096)
>
> 02-Oct-2015 18:03:01.190 general: error: socket: file descriptor
> exceeds limit (4096/4096)
>
> 02-Oct-2015 18:03:01.190 general: cri
-2015 18:03:01.190 general: critical: resolver.c:1784:
INSIST(fctx->references > 1) failed
02-Oct-2015 18:03:01.190 general: critical: exiting (due to assertion
failure)
Neil
___
Please visit https://lists.isc.org/mailman/listinfo/bind-us
On 28 July 2015, ISC publicly disclosed CVE-2015-5477
("An error in handling TKEY queries can cause named to exit with
a REQUIRE assertion failure.")
We would like to inform all readers of this list that the official
copy of this CVE (https://kb.isc.org/article/AA-01272) has been
Hi Ben
On Tue, Jul 28, 2015 at 07:38:35PM -0400, Ben Croswell wrote:
> Absolutely there is a division of traffic. One set of servers hosting
> domains for the outside and another set with no inbound port 53 other than
> stateful replies to internally generated queries.
Keep in mind that some inte
Absolutely there is a division of traffic. One set of servers hosting
domains for the outside and another set with no inbound port 53 other than
stateful replies to internally generated queries.
Just looking to prioritize patching schedules.
On Jul 28, 2015 7:33 PM, "/dev/rob0" wrote:
> On Tue,
On Tue, Jul 28, 2015 at 07:06:16PM -0400, Ben Croswell wrote:
> Is it safe to say the only vulnerable hosts would be those
> accepting queries from the outside world, or would this also
> pertain servers getting responses from the outside world with
> no inbound queries?
I would ask where does the
Is it safe to say the only vulnerable hosts would be those accepting
queries from the outside world, or would this also pertain servers getting
responses from the outside world with no inbound queries?
On Jul 28, 2015 5:42 PM, "Michael McNally" wrote:
> As the security incident manager for this
As the security incident manager for this particular vulnerability
notification, I'd like to say a little extra, beyond our official
vulnerability disclosure (https://kb.isc.org/article/AA-01272)
about this critical defect in BIND.
Many of our bugs are limited in scope or affect only users having
isc_thread_yield()+0x7ffe903ad1dc
> 06-Jan-2015 01:33:33.496 #9 0x7fff90679279 in
> isc_thread_yield()+0x7ffe903ad159
> 06-Jan-2015 01:33:33.496 #10 0x7fff906774b1 in
> isc_thread_yield()+0x7ffe903ab391
> 06-Jan-2015 01:33:33.496 exiting (due to assertion failure)
>
> Any suggestions or
1
06-Jan-2015 01:33:33.496 exiting (due to assertion failure)
Any suggestions or ideas what caused it and how to prevent in the future?
Let me know any more info that is required.
Thanks,
James.
___
Please visit https://lists.isc.org/mailman/listinfo/
Hi,
I just tried firing up BIND 9.10.0a2 on one of our recursive
servers, and after a relatively short while I got:
Feb 17 09:34:26 oliven named[19939]: name.c:534: REQUIREname) != ((void
*)0)) && (((const isc__magic_t *)(name))->magic == ((('D') << 24 | ('N') << 16
| ('S') << 8 | ('n')
[22328]: #7 0x7f805eec21cd in ??
Feb 11 11:49:48 named[22328]: exiting (due to assertion failure)
Only the second startup worked.
Thanks
Klaus
On 11.02.2014 12:44, Klaus Darilion wrote:
Hi all!
I just managed to "crash" Bind 9.9.5 with an assertion failure - see
attached log file.
W
Hi all!
I just managed to "crash" Bind 9.9.5 with an assertion failure - see
attached log file.
What my script does is:
1. delete zone via rndc (in this case the zone does not exist)
2. add zone via rndc
3. rndc signing -nsec3param
4. rndc sign
5. rndc signing -
On Mon, Dec 02, 2013 at 04:57:15PM +0100, Harald A. Irmer wrote:
> 2 named exits cause due to assertion failure:
>
> 01-Dec-2013 00:57:01.855 general: critical: zt.c:166: REQUIREzt) !=
> ((void *)0)) && (((const isc__magic_t *)(zt))->magic == ((('Z') <<
Hi,
2 named exits cause due to assertion failure:
01-Dec-2013 00:57:01.855 general: critical: zt.c:166: REQUIREzt) !=
((void *)0)) && (((const isc__magic_t *)(zt))->magic == ((('Z') << 24 |
('T') << 16 | ('b') << 8 | ('l&#
Assertion
Failure in BIND9
Summary: High numbers of queries with DNSSEC validation enabled can
cause an assertion failure in named, caused by using a "bad cache" data
structure before it has been initialized.
CVE: CVE-2012-3817
Document Version: 2.0
Posting date: 24 July, 2012
Program Impac
On Jul 3, 2012, at 10:58 AM, wbr...@e1b.org wrote:
> Jan-Piet wrote on 07/03/2012 10:41:20 AM:
>
>> Building BIND is easy; turning it into an installable RPM not so.
>> I highly recommend fpm [1] which makes building an RPM trivial. :)
>
> Any advice or tricks for making a DEB for Ubuntu?
>
>
> > Building BIND is easy; turning it into an installable RPM not so.
> > I highly recommend fpm [1] which makes building an RPM trivial. :)
>
> Any advice or tricks for making a DEB for Ubuntu?
Yes: use fpm. :)
> So far my plan was to copy the source directory to each server and just
> run "ma
Jan-Piet wrote on 07/03/2012 10:41:20 AM:
> Building BIND is easy; turning it into an installable RPM not so.
> I highly recommend fpm [1] which makes building an RPM trivial. :)
Any advice or tricks for making a DEB for Ubuntu?
So far my plan was to copy the source directory to each server and
> While it's always better to compile and install from the latest
> stable version, it's also nice to use their package management
> system especially when you have to deal with multiple systems.
Building BIND is easy; turning it into an installable RPM not so.
I highly recommend fpm [1] which mak
g] On Behalf Of
Oscar Ricardo Silva
Sent: Tuesday, July 03, 2012 10:33 AM
To: bind-users@lists.isc.org
Subject: Re: bind dies with assertion failure
(Sorry, forgot to include the right Subject line so re-sending)
> Message: 1
> Date: Mon, 02 Jul 2012 17:40:51 -0500 > From: Oscar
(Sorry, forgot to include the right Subject line so re-sending)
> Message: 1
> Date: Mon, 02 Jul 2012 17:40:51 -0500
> From: Oscar Ricardo Silva
> To: bind-users@lists.isc.org
> Subject: Re: bind dies with assertion failure
> Message-ID: <4ff22373.2000...@mail.utexas.edu&
07/03/2012 01:16 AM, Oscar Ricardo Silva wrote:
>> I *THINK* I found the reason for why we're exposed to this bug ...
>> It would appear that Redhat based their BIND package on 9.8.2rc1.
>> Guess where the patch for this bug was applied? 9.8.2rc2.
> Are you sure about this?
> From what I can se
Oscar Ricardo Silva wrote on 07/02/2012 06:40:51 PM:
> The reason I'm running is that we're currently running the stock version
> of BIND available with RHEL6. It's their policy to backport patches and
> if there's a patch available then they may apply it faster rather than
> deploying a new
dies with assertion failure
On 07/03/2012 01:16 AM, Oscar Ricardo Silva wrote:
> I *THINK* I found the reason for why we're exposed to this bug ... It
> would appear that Redhat based their BIND package on 9.8.2rc1. Guess
> where the patch for this bug was applied? 9.8.2rc2.
Are
On 07/03/2012 01:16 AM, Oscar Ricardo Silva wrote:
I *THINK* I found the reason for why we're exposed to this bug ... It
would appear that Redhat based their BIND package on 9.8.2rc1. Guess
where the patch for this bug was applied? 9.8.2rc2.
Are you sure about this?
From what I can see in ou
On Mon, Jul 02, 2012 at 07:16:40PM -0500, Oscar Ricardo Silva wrote:
> I *THINK* I found the reason for why we're exposed to this bug ... It
> would appear that Redhat based their BIND package on 9.8.2rc1. Guess
> where the patch for this bug was applied? 9.8.2rc2.
Sigh. It wouldn't be the fi
,
I have a fedora16 x86_64 box and named keeps dying with an assertion
failure:
14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619:
INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
14-Feb-2012 13:24:41.137 general: critical: exiting (due to assertion
failure)
This is bin
#x27;re working on it already, so
> >stay tuned.
> >
> >--Michael
> >
> >On Feb 14, 2012, at 12:44 PM, Alex wrote:
> >
> >>>Hi,
> >>>
> >>>I have a fedora16 x86_64 box and named keeps dying with an assertion
> >>f
Message: 6
Date: Tue, 14 Feb 2012 14:16:05 -0600
From: Michael Graff
To: Alex
Cc:bind-users@lists.isc.org
Subject: Re: bind dies with assertion failure
Message-ID:<9a4c0b81-4221-465a-a952-3523bd576...@isc.org>
Content-Type: text/plain; charset=us-ascii
It is a known issue, and is indeed a
Is this something I should add to the FreeBSD port?
On 03/14/2012 17:58, Mark Andrews wrote:
>
> We believe this patch will fix this issue. It has been committed to be
> released as part of BIND 9.9.1.
>
> Mark
>
> diff --git a/bin/named/client.c b/bin/named/client.c
> index 2f4130c..ae13795
We believe this patch will fix this issue. It has been committed to be
released as part of BIND 9.9.1.
Mark
diff --git a/bin/named/client.c b/bin/named/client.c
index 2f4130c..ae13795 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -240,7 +240,7 @@ ns_client_recursing(ns_client_t *c
f0e5e714cb7 in ??
> 14-Mar-2012 10:16:22.348 general: critical: #5 0x7f0e5d0cf1dd in ??
> 14-Mar-2012 10:16:22.348 general: critical: #6 0x7f0e5ca857f1 in ??
> 14-Mar-2012 10:16:22.348 general: critical: #7 0x7f0e5bfd792d in ??
> 14-Mar-2012 10:16:22.348 general: critical: exiting (due to
48 general: critical: #6 0x7f0e5ca857f1 in ??
14-Mar-2012 10:16:22.348 general: critical: #7 0x7f0e5bfd792d in ??
14-Mar-2012 10:16:22.348 general: critical: exiting (due to assertion
failure)
BIND had then been running since Mar 12 09:20:46 CET. It's a recursive
server, with somewhat high tra
af
Mar 9 06:58:51 X named[17533]: general: critical: #7 0x3c433c7543 in
_fini()+0x3c42e1a3bb
Mar 9 06:58:51 X named[17533]: general: critical: exiting (due to
assertion failure)
Afte
It is a known issue, and is indeed a bug. We're working on it already, so stay
tuned.
--Michael
On Feb 14, 2012, at 12:44 PM, Alex wrote:
> Hi,
>
> I have a fedora16 x86_64 box and named keeps dying with an assertion failure:
>
> 14-Feb-2012 13:24:41.137 general: cr
Hi,
I have a fedora16 x86_64 box and named keeps dying with an assertion failure:
14-Feb-2012 13:24:41.137 general: critical: rbtdb.c:1619:
INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
14-Feb-2012 13:24:41.137 general: critical: exiting (due to assertion failure)
This
On Wednesday 07 December 2011 16:08:54 Mark Andrews wrote:
> In message <87mxb4xm7t@mid.deneb.enyo.de>, Florian Weimer
writes:
> > * Mark Andrews:
> > > BIND 9.2.1 was released May 2002 and is no longer supported.
> >
> > Uhm, there are multiple sources for BIND support. At least one
> > sti
In message <87mxb4xm7t@mid.deneb.enyo.de>, Florian Weimer writes:
> * Mark Andrews:
>
> > BIND 9.2.1 was released May 2002 and is no longer supported.
>
> Uhm, there are multiple sources for BIND support. At least one still
> provides some coverage for BIND 9.2.
I wouldn't want to run 9.2.
version of BIND.)
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
Florian Weimer
Sent: Wednesday, December 07, 2011 1:37 PM
To: Mark Andrews
Cc: bind-us...@isc.org
Subject: Re: bind
* Mark Andrews:
> BIND 9.2.1 was released May 2002 and is no longer supported.
Uhm, there are multiple sources for BIND support. At least one still
provides some coverage for BIND 9.2.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users
ceived following message :
>
> named: resolver.c:4030: REQUIREquery) != 0L) && (((const isc__magic_t *)(
> query))->magic == ((('Q') << 24 | ('!') << 16 | ('!')<< 8 | ('!')) failed
> named: exiting (due to as
On 03/29/2011 00:32, Oleksii Krykun wrote:
Hi,
I used BIND 9.4.3-P2 on FreeBSD 7.2-RELEASE
7.2 is past EOL. Please see
http://www.freebsd.org/security/security.html#sup for more information.
My recommendation would be to use at least 8.2-RELEASE. At that point
you may wish to upgrade to 8-
On 04/01/2011 14:07, Kevin Oberman wrote:
Date: Fri, 1 Apr 2011 08:56:14 +0200
From: Matus UHLAR - fantomas
Hasn't FreeBSD incorporated BIND9.4-ESV ?
Define "incorporated" :)
The 7.4-RELEASE has 9.4-ESV-R4. But the OP is on an older version of
FreeBSD.
You can always install newer from
ut problems.
> >
> > Since last Friday sometimes I see error messages like following:
> >
> > Mar 28 16:44:06 gate2 named[60455]:
> > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2361:
> > INSIST(!sock->pending_accept) failed
> &g
/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2361:
> INSIST(!sock->pending_accept) failed
> Mar 28 16:44:06 gate2 named[60455]: exiting (due to assertion failure)
> Mar 28 16:44:06 gate2 kernel: pid 60455 (named), uid 53: exited on signal 6
Hasn't FreeBSD incorporated BIND9.4-E
->pending_accept) failed
Mar 28 16:44:06 gate2 named[60455]: exiting (due to assertion failure)
Mar 28 16:44:06 gate2 kernel: pid 60455 (named), uid 53: exited on signal 6
What is a reason of this problem? No any system configuration changes were
made last time.
I use BIND as caching DNS server for a
to
rebuild it with enabling epoll (which should be enabled by default on
your Linux system) and try again.
In any case, the assertion failure should be a bug, but right now I
have no idea about how it happened.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
__
in ??
>> Apr 26 19:20:54 ha1 named[3891]: #2 0x7dfc03 in ??
>> Apr 26 19:20:54 ha1 named[3891]: #3 0x7e16f9 in ??
>> Apr 26 19:20:54 ha1 named[3891]: #4 0x7e1979 in ??
>> Apr 26 19:20:54 ha1 named[3891]: #5 0x7e1be7 in ??
>> Apr 26 19:20:54 ha1 named[3891]: #6 0x61a49
?
Apr 26 19:20:54 ha1 named[3891]: #5 0x7e1be7 in ??
Apr 26 19:20:54 ha1 named[3891]: #6 0x61a49b in ??
Apr 26 19:20:54 ha1 named[3891]: #7 0x6fd42e in ??
Apr 26 19:20:54 ha1 named[3891]: exiting (due to assertion
failure)
Any advice given the info provided below? Let me know if I can
provide m
x61a49b in ??
> Apr 26 19:20:54 ha1 named[3891]: #7 0x6fd42e in ??
> Apr 26 19:20:54 ha1 named[3891]: exiting (due to assertion
> failure)
>
> Any advice given the info provided below? Let me know if I can provide
> more info.
>
> Dale
>
>
> $ dig +short version.b
med[3891]: #6 0x61a49b in ??
Apr 26 19:20:54 ha1 named[3891]: #7 0x6fd42e in ??
Apr 26 19:20:54 ha1 named[3891]: exiting (due to assertion
failure)
Any advice given the info provided below? Let me know if I can provide
more info.
Dale
$ dig +short version.bind chaos txt
"9.7.0-P1"
Ok, I think I've included what your looking for below. If it's not the
right thing please let me know how to generate what your looking for
from the core dump. I will readily admit this level of debugging isn't
something I'm very familiar with.
If you want to try to reproduce it I made a little
At Thu, 26 Feb 2009 07:58:29 -0600,
Timothy Holtzen wrote:
> No it is a single processor on both production and test systems.
> Production is an Opteron and the test system is an Athlon64 but both are
> single core processors. Just to be sure I did a configured with a
> --disable-threads on the
1:12 arthur named[17030]: statschannel.c:744: INSIST(xmlrc >=
>> 0) failed
>> Feb 25 13:51:12 arthur named[17030]: exiting (due to assertion failure)
>>
>> Since it failed with the full patch I figured removing xmlInitParser()
>> wouldn't make a difference. I d
arthur named[17030]: exiting (due to assertion failure)
>
> Since it failed with the full patch I figured removing xmlInitParser()
> wouldn't make a difference. I decided to try anyway and got the same
> result.
Okay, thanks for the confirmation. Are you running named with
mult
: XML error 9 !
Feb 25 13:51:12 arthur named[17030]: libxml2 Error: write error
Feb 25 13:51:12 arthur named[17030]: statschannel.c:744: INSIST(xmlrc >=
0) failed
Feb 25 13:51:12 arthur named[17030]: exiting (due to assertion failure)
Since it failed with the full patch I figured removing xmlInitPar
At Tue, 24 Feb 2009 14:26:45 -0600,
Timothy Holtzen wrote:
> Hi guys I'm getting this assertion failure again under Bind 9.5.1-P1 on
> RHEL 5.2.
>
> Feb 23 22:00:01 foo named[18476]: statschannel.c:696: INSIST(xmlrc >= 0)
> failed
> Feb 23 22:00:01 foo named[18476]:
Hi guys I'm getting this assertion failure again under Bind 9.5.1-P1 on
RHEL 5.2.
Feb 23 22:00:01 foo named[18476]: statschannel.c:696: INSIST(xmlrc >= 0)
failed
Feb 23 22:00:01 foo named[18476]: exiting (due to assertion failure)
I posted about it once before. I understand that this i
>
> Jan 14 17:46:38 wdmdc-dns-dts2 named[1415]: [ID 873579 daemon.crit]
> name.c:1714: INSIST(nlabels == name->labels) failed
> Jan 14 17:46:38 wdmdc-dns-dts2 named[1415]: [ID 873579 daemon.crit]
> exiting (due to assertion failure)
This is a different problem; the a
]
name.c:1714: INSIST(nlabels == name->labels) failed
Jan 14 17:46:38 wdmdc-dns-dts2 named[1415]: [ID 873579 daemon.crit]
exiting (due to assertion failure)
One thing I CAN tell you, however, is that I was testing a script on
this box earlier in the day and ran
rndc -cache dumpdb
probably aroun
15:01 foo named[29625]: exiting (due to assertion failure)
>
> Anyone have any idea why this would happen or how I can keep it from
> happening again? I notice that the failure is happening in
This assertion failure was triggered due to a failure of
xmlTextWriterEndElement(). In the
Last night one of our name servers stopped unexpectedly. Looking in the
logs I found the following messages.
Jan 13 20:15:01 foo named[29625]: statschannel.c:696: INSIST(xmlrc >= 0)
failed
Jan 13 20:15:01 foo named[29625]: exiting (due to assertion failure)
Anyone have any idea why this wo
Fr34k wrote:
> Hello,
>
> Running 9.5.1b2
The release version of 9.5.1 is out. It's never a good idea to
continue running betas or release candidates after the release is out.
hth,
Doug
___
bind-users mailing list
bind-users@lists.isc.org
https://lis
Hello,
Running 9.5.1b2 on Solaris9.
Crashed with this info:
Dec 31 13:04:25 named[308]: [ID 873579 daemon.crit] rbtdb.c:1482:
REQUIRE((node)->references > 0) failed
Dec 31 13:04:25 named[308]: [ID 873579 daemon.crit] exiting (due to assertion
failure)
Dec 31 13:05:07 genunix: [ID
92 matches
Mail list logo
