| Subject: | dhclient assertion failure in dns_client_cancelupdate() |
| Date: | Mon, 16 Feb 2015 19:29:28 +0100 |
| To: | dhcp-bugs@isc.org |
| From: | "Jiri Popelka" <jpopelka@redhat.com> |
Hello,
our customer reported that with the attached dhclient.conf dhclient
crashes during address renewal with the following backtrace:
#0 dns_client_cancelupdate (trans=0x2e332e30313d7265) at
../../../lib/dns/client.c:2847
#1 0x00007fabd2c00a4d in ddns_cancel (ddns_cb=0x7fabd3adab30,
file=file@entry=0x7fabd2c23034 "dhclient.c", line=line@entry=4618) at
dns.c:1774
#2 0x00007fabd2beb540 in dhclient_schedule_updates
(client=client@entry=0x7fabd3ad5cc0, addr=0x7fabd3ad6b20,
offset=offset@entry=1) at dhclient.c:4618
#3 0x00007fabd2beb8f5 in bind_lease
(client=client@entry=0x7fabd3ad5cc0, siaddr=<optimized out>) at
dhclient.c:1745
#4 0x00007fabd2bec366 in dhcpack (packet=0x7fabd3ad6920) at dhclient.c:1666
#5 0x00007fabd2be63b6 in dhcp (packet=0x7fabd3ad6920) at dhclient.c:1915
#6 0x00007fabd2c0cbaa in do_packet (interface=0x7fabd3acd340,
packet=<optimized out>, len=312, from_port=17152, from=...,
hfrom=0x7fff5faac8b0) at options.c:3860
#7 0x00007fabd2bfc4e0 in got_one (h=0x7fabd3acd340) at discover.c:1077
#8 0x00007fabd27a3236 in omapi_iscsock_cb (task=<optimized out>,
socket=<optimized out>, cbarg=0x7fabd3ad6c10, flags=1) at dispatch.c:174
#9 0x00007fabd222dfbd in internal_fdwatch_read (me=0x7fabd2b22010,
ev=0x7fabd2b3d570) at ../../../../lib/isc/unix/socket.c:3533
#10 0x00007fabd223588e in dispatch (manager=0x7fabd2b1e010) at
../../../lib/isc/task.c:1116
#11 isc__taskmgr_dispatch (manager0=0x7fabd2b1e010) at
../../../lib/isc/task.c:1616
#12 0x00007fabd223988e in evloop (ctx=0x7fabd2b1d010) at
../../../../lib/isc/unix/app.c:512
#13 isc__app_ctxrun (ctx0=0x7fabd2b1d010) at
../../../../lib/isc/unix/app.c:711
#14 0x00007fabd2bfdfd4 in dispatch () at dispatch.c:113
The line numbers are from 4.1.1, so take them with a bit of salt.
But I've been able to reproduce it even with 4.3.2b1 using that
dhclient.conf
I think I've figured out what's wrong using valgrind, see attached
valgrind output (line numbers there are from 4.3.2b1).
It tells us that at some point in time the ddns_cb structure was freed
in client_dns_update_action()
but client->ddns_cb was probably still pointing to the freed memory,
because later in bind_lease() -> dhclient_schedule_updates() we run
ddns_cancel()
which accesses the already freed memory and the assertion in
dns_client_cancelupdate()
failed, because the transaction contained random stuff.
I failed to find some elegant solution (how to NULL client->ddns_cb
after ddns_cb_free()) as I don't understand the dhclient's ddns workflow
enough.
With regards,
Jiri Popelka
Red Hat, inc.
Message body is not shown because sender requested not to inline it.
Message body is not shown because sender requested not to inline it.