[gecode-users] Bugs with tuples+EPK_SPEED and sequence

[Manuel Baclet]

This is a duplicate of another message (attachment went wrong).

Hi Guido,
thanks for the fix. I have found two other problems (using osX 10.8). When possible, i tried with Gecode 3.7.3 and the trunk version.

- EPK_SPEED does not work with restart search and several threads. I provide an example:


This gives me seg faults. gdb says:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
[Switching to process 8791read 0x1203]
0x000000010004cbcd in Gecode::Int::Extensional::Incremental<Gecode::Int::BoolView>::remove_support (this=0x103008990, home=@0x102800000, l=0x101308280, i=1, n=1) at incremental.hpp:254
254	      while ((*a)->t != l) {


- sequence is not working properly with restart search and several threads. An example:

This gives different random error messages including Segmentation fault: 11, Abort trap: 6 and 
<<test2(8717,0x10d484000) malloc: *** error for object 0x7fb3c3c081d0: pointer being freed was not allocated
     *** set a breakpoint in malloc_error_break to debug>>


gdb reports one of the following error (depending on the execution):
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 8828 thread 0x1203]
0x00000001001a1f78 in Gecode::IntSet::~IntSet () at core.hpp:2286
2286	      delete o;
or 
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 8834 thread 0x1203]
Gecode::VarImp<Gecode::Int::IntVarImpConf>::advise (this=<value temporarily unavailable, due to optimizations>, home=@0x1013086d0, me=1, d=@0x1012cee20) at core.hpp:3346
3346	      switch (p.advise(home,*a,d)) {
or
test2(8866,0x1012cf000) malloc: *** error for object 0x1013081f0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
[Switching to process 8866 thread 0x1203]
0x00007fff916e2212 in __pthread_kill ()


The following example shows that this can also happen with bab search:


Hope you can fix this,
Cheers,
Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cp
Type: application/octet-stream
Size: 1488 bytes
Desc: not available
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0003.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.cp
Type: application/octet-stream
Size: 1326 bytes
Desc: not available
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0004.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test3.cp
Type: application/octet-stream
Size: 1375 bytes
Desc: not available
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0005.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20120807/3f6f6fbb/attachment-0007.html>