I didn't saw your comments and pushed the patches to master
after a make test.
Feel free to revert them if you want.
> On Fri, 2010-01-29 at 15:31 +0200, Kamen Mazdrashki wrote:
>> Hi Simo,
>> On Fri, Jan 29, 2010 at 15:13, simo <idra@xxxxxxxxx> wrote:
>>> Kamen can you explain in what case a recursion can happen for the same
>>> request ?
>>> I need to understand what bug you are trying to fix here to say whether
>>> or not this patch is a good idea.
>> The commit before the fix-commit implements such a test to reveal this bug?
>> (But I guess you are not asking this right) :)
>> Anyways, here is how I hit this bug in first place.
>> I was implementing --show-binary for ms-prefixMap attribute value.
>> It happens that bot Samba4 and AD use the same attribute, but with
>> different format for data.
>> Thus in ldif_write() function for prefixMap, I decided to check if the
>> ldb_context is against Samba4
>> implementation or against Windows AD - I made a search for
>> "vendorName" in RootDSE.
>> At this point I got SEGFAULT - it turns out this SEGFAULT happens in
>> implemented by ldbsearch utlity. SEGFAULT happens because when we read
>> SEARCH_DONE tag
>> on the wire, we triger callback notification, which in turns
>> mistakenly sends LDAP_SEARCH_RESULT
>> value (which value we are alredy processing) again to the
>> ldb_search_callback() function.
>> It became a quite messy explanation, sorry for that...
> Nested ldap searches shouldn't cause this.
> Each search is ties to its own request, and each request on the wire has
> a specific id, so we correctly match replies with requests.
> It looks like there seem to be either a misuse of the interface or a bug
> deep within it. Your fix, at first sight, looks like a bit of bandaid
> that covers a worse problem.
> Can you please show me the segfault you are getting ?
> It looks to me the test you made abuses the interface. I lean to think
> your callback is the cause of the segfault and not ldb_ildap code.