Hi, Sorry, forget to add mail list on last reply.
> However, looking more closely at the code, particularly delete_dep_node, it > explicitly assumes that it won't be called with a node that is on another > list. So it would indeed seem like the shallow copy is expected by design > and other mechanisms are in place to avoid the double-free. Sure, I will double-check my code to conform this assumption. I will write if I will find simple way to break anything inside, say, x86 backend to be easily reproduced by you. --- With best regards, Konstantin On Wed, Oct 21, 2015 at 7:52 PM, Jeff Law <l...@redhat.com> wrote: > On 10/20/2015 10:06 AM, Konstantin Vladimirov wrote: >> >> Hi, >> >> Inside custom backend, if I do have insn and insn2, insn can be >> deleted when changing insn2, and also all dependencies should be >> preserved. So I did something like: >> >> sd_copy_back_deps (insn2, insn, true); >> >> for (sd_it = sd_iterator_start (insn, SD_LIST_RES_BACK); >> sd_iterator_cond (&sd_it, &dep);) >> sd_delete_dep (sd_it); >> >> sd_finish_insn (insn); >> delete_insn (insn); > > Isn't this fundamentally broken WRT the comment in delete_dep_node which > says that the to-be-deleted code must not be on any deps_list? > > >> >> Then everything goes ok, but after all, sheduler also frees >> dependencies from insn2, thus doing double freeing. > > Just to be clear, I can see on a conceptual level that the shallow copy can > potentially cause a problem with possibly calling delete_dep_node more than > once on a particluar dep_node. > > However, looking more closely at the code, particularly delete_dep_node, it > explicitly assumes that it won't be called with a node that is on another > list. So it would indeed seem like the shallow copy is expected by design > and other mechanisms are in place to avoid the double-free. > > What are those mechanisms, and can you use them to avoid the double-free > problem? > > jeff >
