On 30 Mar 2012, at 18:48, Jean-Noël Monette wrote:
> Hi Guido,
>
> You are totally right and this is indeed a bug in my (real) code, and I will
> change it accordingly. However, in the small example, I get the same problem
> when u0 is created using region1 instead of region2, i.e.
>
> Region region1(home);
> Iter::Ranges::NaryUnion u0;
> {
> Region region2(home);
> u0 = Iter::Ranges::NaryUnion(region1,dom0); //region1 here
> }
> Iter::Ranges::NaryUnion u1(region1,u0,dom1);
>
>
> In this case, as far as I understand, there should be no dangling pointer, as
> u0 is initialized with memory from region1. Or do the two regions share their
> memory, and the destruction of region2 affects the memory of region1?
Right, that's a bug. You currently can't use region1 while another "inner"
region is active (i.e., in scope). That's a bug and requires rewriting the
region code, so it will have to wait until a future release. Sorry about that.
Cheers,
Guido
>
> Thank you for you answers, and sorry for the inconvenience.
>
> Jean-Noël
>
> On 03/30/2012 12:41 AM, Guido Tack wrote:
>> On 29/03/2012, at 7:56 PM, Jean-Noël Monette wrote:
>>
>>> Hello,
>>>
>>> Here is a new problem I came across with NaryUnion. As suggested by
>>> Christian, I created a fresh region for every new NaryUnion, however I ran
>>> into an infinite loop. Below is a minimal example. I located the infinite
>>> loop inside the "two(I& i, J& j)" method of NaryUnion, and the reason
>>> seems to be that, after the call to "RangeList* t = range(j)" in the "else
>>> if" block (I unfortunately cannot give you line numbers as I messed around
>>> with print statements), "i.c" and "t" point to the very same RangeList
>>> (while they should not). I'm not expert enough to go deeper/further...
>>>
>>> Notice that this appears only when region2 is created in a block (in real
>>> code, it would be inside a "for" or a "if"), however there is no influence
>>> if it is actually used or not.
>>>
>>> I guess it is again related to the Region implementation that is going to
>>> change, but I think it is worth mentioning it anyway.
>> Memory allocated from a region only lives as long as the region, and by
>> passing u0 out of its region's scope, you get a dangling pointer. It's like
>> writing
>>
>> char* c;
>> { string s = "hello"; c = s.c_str(); }
>> string s = "world";
>> printf("%s",c);
>>
>> which will probably print world rather than hello. So I'd say this is a bug
>> in your code (and we should improve the documentation to make this clear).
>>
>> Cheers,
>> Guido
>>
>>
>
> _______________________________________________
> Gecode users mailing list
> users@gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
--
Guido Tack,
http://www.csse.monash.edu/~guidot/
_______________________________________________
Gecode users mailing list
users@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
