[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heimdal 0.6.2 coredumps

On Tue, 29 Mar 2005 14:05:52 +0200
fandino <fandino@ng.fadesa.es> wrote:

> do you think I must try to run a snapshot?

I'm running the 20050220 snapshot (with openldap-2.3.2 beta on Sol
10/X86) and I'm getting a crash in what looks like the same place:

   Program received signal SIGSEGV, Segmentation fault.
   0xd0e3a580 in try_read1msg (ld=0x806ff98, msgid=5, all=1,
   sb=0x8071590, lcp=0x8047620, result=0x80476f4) at result.c:866
   (gdb) where
   #0  0xd0e3a580 in try_read1msg (ld=0x806ff98, msgid=5, all=1,
   sb=0x8071590, lcp=0x8047620, result=0x80476f4) at result.c:866
   #1  0xd0e3979e in wait4msg (ld=0x806ff98, msgid=5, all=1,
   timeout=0x0, result=0x80476f4) at result.c:343
   #2  0xd0e3910f in ldap_result (ld=0x806ff98, msgid=5, all=1,
   timeout=0x0, result=0x80476f4) at result.c:122
   #3  0xd0e3c15b in ldap_search_s (ld=0x806ff98, base=0x8070198
   "cn=ldapadmin,dc=cise,dc=ufl,dc=edu", scope=2, filter=0xd0f613e0
   "(objectClass=krb5Principal)", attrs=0xd0f72720, attrsonly=0,
   res=0x80476f4) at search.c:362
   #4  0xd0f56687 in LDAP_dn2principal (context=0x806e040, db=0x806fe48,
   dn=0x8070198 "cn=ldapadmin,dc=cise,dc=ufl,dc=edu", principal=0x8047804)
   at hdb-ldap.c:770
   #5  0xd0f5715c in LDAP_message2entry (context=0x806e040,
   db=0x806fe48, msg=0x8071608, ent=0x80477f0) at hdb-ldap.c:1075
   #6  0xd0f578a0 in LDAP_seq (context=0x806e040, db=0x806fe48, flags=0,
   entry=0x80477f0) at hdb-ldap.c:1358
   #7  0xd0f57ada in LDAP_nextkey (context=0x806e040, db=0x806fe48,
   flags=0, entry=0x80477f0) at hdb-ldap.c:1433
   #8  0xd0f5895f in hdb_foreach (context=0x806e040, db=0x806fe48,
   flags=0, func=0xd0f85862 <foreach>, data=0x8047880) at hdb.c:161
   #9  0xd0f85a13 in kadm5_s_get_principals (server_handle=0x806fd60,
   exp=0x8047c42 "*", princs=0x80478f0, count=0x80478ec) at
   #10 0xd0fb3648 in kadm5_get_principals (server_handle=0x806fd60,
   exp=0x8047c42 "*", princs=0x80478f0, count=0x80478ec) at
   #11 0x08058afc in foreach_principal (exp=0x8047c42 "*",
   func=0x8054f9b <do_get_entry>, funcname=0x805b678 "get", data=0x8047920)
   at util.c:505
   #12 0x080553d8 in getit (opt=0x8047a30, name=0x805b67c "list",
   argc=1, argv=0x8047b2c) at get.c:382
   #13 0x08055487 in list_princs (opt=0x8047a30, argc=1, argv=0x8047b2c)
   at get.c:405
   #14 0x0805a6a8 in list_wrap (argc=3, argv=0x8047b24) at
   #15 0xd0f31fae in sl_command (cmds=0x806dc20, argc=3, argv=0x8047b24)
   at sl.c:234
   #16 0x0805627c in main (argc=3, argv=0x8047b24) at kadmin.c:261

I get the same thing on Linux.

This looks like an OpenLDAP bug

	if (l->lm_chain == NULL) {
		if ((l->lm_msgtype == LDAP_RES_SEARCH_ENTRY) ||
			(l->lm_msgtype == LDAP_RES_SEARCH_REFERENCE) ||
			(l->lm_msgtype == LDAP_RES_INTERMEDIATE)) {
			/* do not advance lm_chain_tail in this case */
			l->lm_chain = new;
		} else {
			/*FIXME: ldap_msgfree( l );*/
			l = new;
			l->lm_chain_tail = new;
	} else {
=>		if ((l->lm_chain_tail->lm_chain->lm_msgtype
			l->lm_chain_tail->lm_chain->lm_chain = new;
			l->lm_chain_tail = l->lm_chain_tail->lm_chain;
		} else {
			/*FIXME: ldap_msgfree( l->lm_chain_tail->lm_chain );*/
			l->lm_chain_tail->lm_chain = new;

The struct l looks like this:

3: *l = {lm_msgid = 2, lm_msgtype = 100, lm_ber = 0x8070920, lm_chain = 0x8071630, 
         lm_chain_tail = 0x0, lm_next = 0x0, lm_time = 0}

Oops. It looks like l->lm_chain is set, but l->lm_chain_tail isn't. I think
this should probably be reported to the OpenLDAP list. I'll do so unless 
someone thinks this is a heimdal bug.

| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh@cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |