[gecode-users] NaryUnion, infinite loop

[Christian Schulte]

Hi,

The problem is really that both iterators must allocate from the same
region. You should try to avoid the assignment operator for NaryUnion (I
should have not implemented it in the first place, because I know it is
troublesome). Normally there should be no reason to use an assignment
operator, just initialize when you create or use the copy constructor.

Sorry
Christian

--
Christian Schulte, www.ict.kth.se/~cschulte/


> -----Original Message-----
> From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On
> Behalf Of Jean-Noël Monette
> Sent: Friday, March 30, 2012 9:49 AM
> To: users at gecode.org
> Subject: Re: [gecode-users] NaryUnion, infinite loop
> 
> 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?
> 
> 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 at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users