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.