[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6616) back-sql crashing



> 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.