[Date Prev][Date Next]
Re: (ITS#6616) back-sql crashing
> email@example.com wrote:
>>> Attempting to create an inetOrgPerson interface to a proprietary
>>> Obviously something wrong at this stage, causes slapd to SEGV.
>>> gdb tells me that in
>>> bsi->bsi_oc is null going into this call.
>>> rc = attr_merge_normalize_one( bsi->bsi_e,
>>> bsi->bsi_op->o_tmpmemctx );
>>> Without any time to absorb any implications, adding this just before
>>> // 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
>> 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
>> A backtrace and a description of the expected and actual values would
>> (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.
> 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