Posted this to the Ubuntu lists, because I solved this issue myself by fixing my DNS settings.  If this is the case with others, this bug is more of a confusing error message than anything else:
-----------------
Not using ubuntu, but this issue is happening to me and seemingly to a lot of folks.
I think I've found the cause.

In my case, it was a matter of incorrectly configured DNS causing creds.get_named_ccache() 
to fail to find the KDC with which to obtain credentials.  No core is being dumped in my case;
I was just getting this famous stack dump when trying to do:
    /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names
as is suggested in the how-to I was reading to set up Samba.

A couple minutes with strace revealed that it was trying to look up vmnet-dc1.vmnet.us
using my upstream ISP's name server.  At first I just put 127.0.0.1 in the /etc/krb.conf for
the kdc and admin_server settings in the [realms] section.  This got me past the stacktrace
but I was stilling getting a lot of '. .. blah blah blah not found' errors.  Then I realized that
I had left my ISP DNS in /etc/resolv.conf when I was wget-ing a needed source tarball, and
forgot to set it back to 127.0.0.1 (to use the samba-populated DNS server locally).
Herp derp derp!  :)  So I set resolv.conf to point at 127.0.0.1 and set krb5.conf to use the
correct DNS names for kdc, etc.  Bingo!  It now works perfectly. 

Bottom line with this "bug" I think is that you need to be VERY careful to set up DNS
right or things will fail.  (DNS tends to be that way)

/etc/resolv.conf:
------------ snip snip -------------------
search vmnet.us
nameserver 127.0.0.1
------------ snip snip -------------------

/etc/krb5.conf
------------ snip snip -------------------
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = VMNET.US
 dns_lookup_realm = false
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 VMNET.US = {
  kdc = vmnet-dc1.vmnet.us
  admin_server = vmnet-dc1.vmnet.us
 }

[domain_realm]
 .vmnet.us = VMNET.US
 vmnet.us = VMNET.US
------------ snip snip -------------------

this bug is still persistent in release 4.0.9.
Sometimes it leads into a crash if copying data from share to windows client.
In my tests it always failed after copying  around 250 MB of files.
It also has the effect that on my debian system ver.6.0.7 , if this error situation occours , i have to restart the systems network 
(i have to "invoke-rc.d networking restart") 

It would be nice if this could be solved.

Created attachment 11196 [details]
Command 'samba_dnsupdate' results

Comment on attachment 11196 [details]
Command 'samba_dnsupdate' results

I had the same error on my CentOS 7.1.1503 (Core) and Samba 4.2.2 (compiled from the sources) when I used kinit or samba_dnsupdate commands.

I've configured my domain zone (DEV.LOC) manually within the MIT Kerberos recommends
--
$TTL 86400
@		IN	SOA	brooklyn.dev.loc. hostmaster.dev.loc. (
				2015062300;
				3H;
				2H;
				1W;
				3H);
		IN	NS	brooklyn.dev.loc.
brooklyn	IN	A	172.16.1.151

_kerberos		TXT	"DEV.LOC"

ns			CNAME	brooklyn.dev.loc.
kerberos		CNAME	brooklyn.dev.loc.
ldap			CNAME	brooklyn.dev.loc.
_ldap._tcp		SRV	0 0 389	brooklyn.dev.loc.
_kerberos._udp		SRV	0 0 88	brooklyn.dev.loc.
_kerberos-master._udp	SRV	0 0 88	brooklyn.dev.loc.
_kerberos-adm._tcp	SRV	0 0 749	brooklyn.dev.loc.
_kpasswd._udp		SRV	0 0 464	brooklyn.dev.loc.

After that I've added the firewalld rules for ports: 53/udp, 88/udp, 389/tcp and 464/tcp.

And I have made the SELinux changes:
samba_domain_controller --> on
named_write_master_zones --> on
kerberos_enabled --> on
chcon -t named_conf_t /usr/local/samba/private/dns.keytab
chcon -t named_conf_t /usr/local/samba/private/named.conf.update
chcon -t named_var_run_t /usr/local/samba/private/dns
chcon -t named_var_run_t /usr/local/samba/private/dns/DEV.LOC.zone
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/DEV.LOC.zone

this is probably not an issue any more.