client.c Assertion Failure

[smallpond]

Ken Schweigert wrote:
> 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


client_request is being called with a bad argument.  Does your
log have a stack trace showing what called client_request?

You can turn on additional logging with the rndc trace command.

-- S