Thomas Pressnell wrote:
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
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/