tpretz@gmail.com wrote:

This thread is working with the same operation ...0aa0, but performing a standard search as i would expect given the filter value. Somehow ss->s_op seems to have ended up pointing at what seems to be an unreleated operation.

Looking at the code i believe the issue could trigger when an op is abandoned early before syncprov_op_search has got hold of the si_ops lock for the psearch sop.

OK, this sort of makes sense. But abandoning the op doesn't free it immediately, the frontend can't do that until all of the request functions have returned. And the op structure can't get freed and reused by some other op until after that.

I have added a standard o_abandon check and return at line 2574 of syncprov.c while the si_ops lock is held, before sop is added to the list. This seems to have fixed the issue in my testing, i can see this code path is traversed (as i am logging it) a number of times over the last few days of running the tests.

But this can't be an adequate fix, since op->o_abandon could be set at any time after line 2574 as well.

I can provide more detailed backtraces if required.

If you would like core dumps this will require extra time as i would have to replicate the test with non company data / schemas.

Thanks

Tom