Re: Shallow copy error in scheduler deps?

[Konstantin Vladimirov <konstantin dot vladimirov at gmail dot com>]

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 <law@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
>