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:kelb...@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:kelb...@fel.cvut.cz] >> Sent: Monday, May 25, 2009 5:08 PM >> To: Christian Schulte >> Cc: us...@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/ >>> >>> _______________________________________________ Gecode users mailing list us...@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
