client.c Assertion Failure
Mark Andrews
Mark_Andrews at isc.org
Thu Aug 24 01:21:49 UTC 2006
> 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
More information about the bind-users
mailing list