Thomas Pressnell wrote:

Hi,

Looking beyond syncprov.c:2574 o_abandon can be set, however as i understand it once the syncop has been added to the si_ops list its cleanup will be handled by syncprov_op_abandon, we would just need to ensure it has not traversed syncprov_op_abandon before being added to the list.

Reading the rest of syncprov_op_search and syncprov_search_response i notice that syncprov_search_response does check o_abandon (when deciding if to detach the psearch).

In the event of an abandon syncprov_search_response seems to assume syncprov_op_abandon will take care of the cleanup of the syncop, which it wouldn't if syncprov_op_abandon had already been executed before the syncop was added to the si_ops list @~ 2574

OK, thanks. A fix is now in git master. Probably about the same as the one you already described, but please test and feedback.

I would then assume the op is freed, but the syncop remains in the list to be processed. Once reallocated and the o_abandon field is no longer set syncprov_matchops would start to include the syncop in its processing hitting potential issues such as this segv.

Let me know if this ties up with how things really work or if i have misunderstood something along the way.

Thanks

Tom