[gecode-users] Propagator

[Jan Kelbel]

I have access to Linux, so I will check the program with valgrind.

Concerning the crash of notice call, it happens only when it is called 
from copy constructor of the propagator, which I did not see in any 
propagator in Gecode.
Some info from the debugger (which I don't understand since I do not 
know Gecode deep inside) :

Assertion failed: n != 0, file 
../../gecode-source/gecode-3.1.0/gecode/kernel/co
re.cpp, line 125

//in method Space::d_resize(void)
unsigned int n = static_cast<unsigned int>(d_lst - d_fst);
assert(n != 0);   //line 125

and debugger shows d_lst == d_fst == 0xcdcdcdcd

Jan


Christian Schulte napsal(a):
> Hmm, sounds weird. Do you use Linux, then you could use the valgrind tool
> for tracking memory leaks.
> 
> But then, why does the call to notice crash? It very definitely shouldn't.
> 
> Christian
> 
> --
> Christian Schulte, www.ict.kth.se/~cschulte/
> 
> 
> -----Original Message-----
> From: Jan Kelbel [mailto:kelbelj at fel.cvut.cz] 
> Sent: Monday, May 25, 2009 5:24 PM
> To: Christian Schulte
> Subject: Re: [gecode-users] Propagator
> 
> I did it too, with no real effect (the memory used by the process grows 
> by 1MB/s, and for job-shop 8 machines x 8 tasks there are 8 edge-finder 
> propagators, each with SharedArray<Int> of size 8).
> I did not use home.notice(*this,AP_DISPOSE) in copy constructor - it 
> caused crash of the process - but it is neither used in copy 
> constructors in Gecode.
> 
> Jan
> 
> 
> Christian Schulte napsal(a):
>> For a SharedArray, you have to manually call its destructor in the dispose
>> method and you have to use notice/ignore as described before.
>>
>> For an example, see gecode/element/int.hpp
>>
>> Christian
>>
>> --
>> Christian Schulte, www.ict.kth.se/~cschulte/
>>
>>
>> -----Original Message-----
>> From: Jan Kelbel [mailto:kelbelj at fel.cvut.cz] 
>> Sent: Monday, May 25, 2009 5:08 PM
>> To: Christian Schulte
>> Cc: users at gecode.org
>> Subject: Re: [gecode-users] Propagator
>>
>> Hi Christian,
>>
>> thank you for the answer. From the things you described (and I already 
>> tried, though I not really knew what it is doing), it must be something 
>> else. The propagator has one array created in propagate() method using 
>> Region allocator, that should be freed automatically when the 
>> propagate() returns, and one SharedArray that is shared among all the 
>> copies of one propagator.
>>
>> Regards, Jan
>>
>>
>> Christian Schulte napsal(a):
>>> Hi Jan,
>>>
>>> there are the following catches:
>>>
>>> a) propagators do not use destructors. Instead, when a propagator is
>>> deleted, the dispose function is called. That in particular implies that
>> for
>>> any member of your propagator you have to explicitly call the member's
>>> destructor (that is something that is done automatically inside a
>> destructor
>>> but not in the dispose function).
>>>
>>> b) most likely you are under the assumption that when a space containing
>>> your propagator is deleted, the dispose method of the propagator is
> called
>>> such that memory possibly allocated by your propagator is freed. That is
>> not
>>> the case. In case your propagator requires the dispose method to be
> called
>>> when a space is deleted, the propagator must register itself with its
>> space
>>> for deletion. For example, when home refers to the space, you have to
>>> register the propagator by
>>> 	home.notice(*this, AP_DISPOSE);
>>> and consequently in the dispose function you have to deregister
>>> 	home.ignore(*this, AP_DISPOSE);
>>>
>>> The only exception is if your propagator has only allocated memory from
>> the
>>> space but not via malloc or something else. Then it does not be deleted
>> when
>>> its space is deleted.
>>>
>>> Then, the behaviour you describe must have to do with something else as
>>> there is really nothing special happening for NaryPropagator. Maybe you
>>> could check your code again.
>>>
>>> I think you are referring to the Gecode 2.* implementation of the
>>> cumulatives propagator. That was actually nonsensical and has been
> changed
>>> in 3.*. If no variables are modified by a propagator and the propagator
>> says
>>> ES_NOFIX, Gecode still knows that nothing has changed. So finding out
>>> whether something has changed, and if yes reporting ES_NOFIX and ES_FIX
>>> otherwise is exactly the same than reporting ES_NOFIX.
>>>
>>> I hope that helps
>>> Christian
>>>
>>> --
>>> Christian Schulte, www.ict.kth.se/~cschulte/
>>>
>>>