masarati@aero.polimi.it wrote:

...

...

Attempting to create an inetOrgPerson interface to a proprietary database schema. Obviously something wrong at this stage, causes slapd to SEGV.

gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() bsi->bsi_oc is null going into this call.

rc = attr_merge_normalize_one( bsi->bsi_e, slap_schema.si_ad_objectClass, &bsi->bsi_oc->bom_oc->soc_cname, bsi->bsi_op->o_tmpmemctx );

Without any time to absorb any implications, adding this just before the above call

// added without any clue... Rex if ( eid->eid_oc == NULL ) return LDAP_NO_SUCH_OBJECT;

fixes the SEGV, but not my interface.

This should not happen, since that objectClass mapping is explicitly obtained few lines above if missing, and if the entry's OC was known by ID it must be available in the ID to OC mapping. I suspect something like ITS#6617, where the obejctClass' ID overflows the unsigned long. Can you investigate?

A backtrace and a description of the expected and actual values would help (e.g. what ID has the "offending" objectClass, and what ID is backsql_id2entry() actually trying to fetch).

It should be OK, at this point, to give up, but a clear indication that mapping did not succeed needs to be returned.

p.

I've finished my interface and i'm reluctant to share the mess it was in when it caused the server to crash.

What i found was that the call to avl_find() in backsql_id2oc() returned NULL, which got passed back up the stack, used as a pointer and boom.

Without spending a long time trying to decipher the code, i could only guess what any of this means, i'm not an LDAP expert (or even really all that familiar with it).

Please keep replies in CC to the ITS.

In principle, avl_find() must return a valid objectClass; logically, we should assert() that a non-NULL pointer is returned. Determining why this occurs could help fixing the issue. Right now, you're just wiping it under the carpet, by returning a generic error instead of the expected data.

p.