> On 15 Oct 2019, at 06:58, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote: > > So we are finding these race conditions (leading to heap-use-after-free) when you stop the server while an import task is running. The current code aborts the task which leaves the database unusable until it is fully reinitialized at a later time. Unfortunately the code that handles this is complex, and very error prone. > > I'd like to allow the import task to complete before fully shutting the server down. Code fix is trivial, but do we want the import to finish, or should the import be aborted (and database left broken)? Thoughts? Opinions? The question is "what does the admin expect"? I could envisage if you start an import and then cancel the task, you expect: * The task to be immediately stopped * The db content rolled back. Shouldn't we be in a betxn or similar during an import so we can revert? Failing this, I'd assume the user would expect a ctrl-c to immediately cancel the task. What kind of use-after-frees are we seeing? > > Thanks, > > Mark > > -- > > 389 Directory Server Development Team > _______________________________________________ > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx