client.c Assertion Failure

[Mark Andrews]

> For the past two nights one of the bind servers that I manage has
> crashed and throws this error in syslog:
> 
> Aug 23 01:52:28 servr named[3384]: client.c:1143: REQUIRE((((client)
> != ((void *)0)) && (((const isc__magic_t *)(client))->magic == ((('N')
> << 24 | ('S') << 16 | ('C') << 8 | ('c')))))) failed
> Aug 23 01:52:28 servr named[3384]: exiting (due to assertion failure)
> 
> The box is running Debian Sarge (3.1) on x86 with Bind 9.3.2 running
> in a chroot jail.  The box has been running beautifully since April
> this year.
> 
> Here is a snippet of client.c at/around line 1143:
> 
>    1119 /*
>    1120  * Handle an incoming request event from the socket (UDP case)
>    1121  * or tcpmsg (TCP case).
>    1122  */
>    1123 static void
>    1124 client_request(isc_task_t *task, isc_event_t *event) {
>    1125         ns_client_t *client;
>    1126         isc_socketevent_t *sevent;
>    1127         isc_result_t result;
>    1128         isc_result_t sigresult = ISC_R_SUCCESS;
>    1129         isc_buffer_t *buffer;
>    1130         isc_buffer_t tbuffer;
>    1131         dns_view_t *view;
>    1132         dns_rdataset_t *opt;
>    1133         isc_boolean_t ra;       /* Recursion available. */
>    1134         isc_netaddr_t netaddr;
>    1135         isc_netaddr_t destaddr;
>    1136         int match;
>    1137         dns_messageid_t id;
>    1138         unsigned int flags;
>    1139         isc_boolean_t notimp;
>    1140
>    1141         REQUIRE(event != NULL);
>    1142         client = event->ev_arg;
>    1143         REQUIRE(NS_CLIENT_VALID(client));
>    1144         REQUIRE(task == client->task);
> 
> If I had to guess, my guess would be that the client querying the
> server is not valid?  Hardly seems a reason to stop the server.  Or
> maybe somebody is trying something not nice and Bind is stopping as a
> safety measure.
> 
> I also looked around and could not find any core dump files.
> 
> I'm unable to tell anyone how to reproduce the error, but it did
> happen near 2:00am both nights so I assume it will happen again
> tonight.
> 
> Is there anything I can do to get more details about what is
> happening?  Some info I can gather that will help someone help me to
> get this sorted out?
> 
> Thanks.
> 
> -ken

	In general, we need stack traces to go with assertion
	failures to be able to work out what is going wrong.  The
	assertion tells us where the bug was detected.  The stack
	trace, usually, tells us how it occured.

	BIND 9 is built using "Design by Contract".

	Before reporting a bug you should ensure you are running a
	current version.  BIND 9.3.3rc1 is currently available.  I
	would install that and see if the problem re-occurs.  If
	it does please log a bug report with bind9-bugs at isc.org
	along with the stack backtrace.

	Mark

Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 1999-2001  Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.

$Id: DBC,v 1.6 2004/03/05 05:04:49 marka Exp $

Design By Contract

BIND 9 uses the "Design by Contract" idea for most function calls.

A quick summary of the idea is that a function and its caller make a
contract.  If the caller meets certain preconditions, then the
function promises to either fulfill its contract (i.e. guarantee a set
of postconditions), or to clearly fail.

"Clearly fail" means that if the function cannot succeed, then it will
not silently fail and return a value which the caller might interpret
as success.

If a caller doesn't meet the preconditions, then "further execution is
undefined".  The function can crash, compute a garbage result, fail silently,
etc.  Allowing the function to define preconditions greatly simplifies many
APIs, because the API need not have a way of saying "hey caller, the values
you passed in are garbage".

Typically, preconditions are specified in the functions .h file, and encoded
in its body with REQUIRE statements.  The REQUIRE statements cause the program
to dump core if they are not true, and can be used to identify callers that
are not meeting their preconditions.

Postconditions can be encoded with ENSURE statements.  Within the body of
a function, INSIST is used to assert that a particular expression must be
true.  Assertions must not have side effects that the function relies upon,
because assertion checking can be turned off.
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email training at isc.org.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org