[regression][6.3.0] Latest commits potentially cause Attempt to free invalid pointer

[yurivict]

Gecode rev. 0916a1a worked fine for me. However, changing to rev. e86200e causes errors like:

src/tcmalloc.cc:333] Attempt to free invalid pointer 0x7fffffffb2a0

There is a chance that I have a bug but I suspect there is a regression in Gecode.

[yurivict]

Stack of abort:

(gdb) bt
#0  thr_kill () at thr_kill.S:4
#1  0x0000000802091434 in __raise (s=s@entry=6) at /disk-samsung/freebsd-src/lib/libc/gen/raise.c:52
#2  0x00000008021464b9 in abort () at /disk-samsung/freebsd-src/lib/libc/stdlib/abort.c:67
#3  0x00000008009bc0b1 in tcmalloc::Log(tcmalloc::LogMode, char const*, int, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem) () from /usr/local/lib/libtcmalloc.s
o.4
#4  0x00000008009b86a5 in ?? () from /usr/local/lib/libtcmalloc.so.4
#5  0x00000008011d1443 in Gecode::Support::Allocator::free (p=0x289fd, this=<optimized out>) at ./gecode/support/allocator.hpp:88
#6  Gecode::Heap::rfree (p=0x289fd, this=<optimized out>) at ./gecode/support/heap.hpp:377
#7  Gecode::Driver::BaseOption::strdel (s=0x289fd <error: Cannot access memory at address 0x289fd>) at gecode/driver/options.cpp:76
#8  Gecode::Driver::BaseOption::~BaseOption (this=0x7fffffffb690) at gecode/driver/options.cpp:106
#9  0x00000000007304e8 in Gecode::Driver::UnsignedIntOption::~UnsignedIntOption (this=0x7fffffffb690) at /usr/local/include/gecode/driver.hh:228
#10 0x00000000007305df in Gecode::Options::~Options (this=0x7fffffffb0f0) at /usr/local/include/gecode/driver.hh:410

104│     BaseOption::~BaseOption(void) {
105│       strdel(eopt);
106├─────> strdel(iopt);
107│       strdel(exp);
108│     }
109│

[zayenz]

interesting. AFAICS, there is nothing in that sequence of commits in that should lead to such an issue. Do you have more information that you can share about your program and what you are doing?

One of the things changed in the range was that a new option was added for restart limits, but the change follows the pattern for all the other options, so it seems odd that it would trigger such a change.

[yurivict]

My program solves constraint problems with timeout:

bool Solver::solve(
        std::function<void(const Solver &solver)> fnSolution,
        std::function<bool()> fnStop,
        unsigned numCPUs
) {
        // options
        Search::Options options;
        options.threads = numCPUs;
        options.clone = true;

        // timeout
        class Stop : public Search::Stop {
        public:
                std::function<bool()> fnStop;
                bool stop(const Search::Statistics& s, const Search::Options& o) override {
                        return fnStop();
                }
        };
        Stop stop;
        if (fnStop) {
                stop.fnStop = fnStop;
                options.stop = &stop;
        }

        std::unique_ptr<BAB<Solver>> e(new BAB<Solver>(this, options));

        while (auto s = std::shared_ptr<Solver>(e->next()))
                fnSolution(*s);

        return e->stopped();
}

Not all cases fail. On a large QA suite only a few cases begin to fail with the new revision. With the old revision no cases were failing like this.

[yurivict]

It might be that some place wasn't updated for the new option that was added?

[yurivict]

The latest revision e86200e doesn't have this issue.