*** Error in `node': munmap_chunk(): invalid pointer: 0x00007f9b5240f720 ***

[Jim]

Hi,

I get an error when running an OR-tools app on linux. It seems that there is a problem with /libortools.so::operations_research::PathOperator::InitializePathStarts. Does anyone know why this error happens?

Error message:

*** Error in `node': munmap_chunk(): invalid pointer: 0x00007f9b5240f720 ***

Further log

node(_ZNSt10_HashtableIiiSaIiENSt8__detail9_IdentityESt8equal_toIiESt4hashIiENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb1EEEE21_M_insert_unique_nodeEmmPNS1_10_Hash_nodeIiLb0EEE+0x128)[0xa7b6c8]

  5.53323

***C++ output***

aftersolvetsp

afterresize

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research12PathOperator20InitializePathStartsEv+0x746)[0x7f9b53472f46]

after put in array

before delete

afterdeleter

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research12PathOperator19InitializeBaseNodesEv+0x1e)[0x7f9b5347319e]

The order in the first calculation is: 0,2,1,3

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research12PathOperator7OnStartEv+0x9)[0x7f9b534733b9]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research22VarLocalSearchOperatorINS_6IntVarExNS_24IntVarLocalSearchHandlerEE5StartEPKNS_10AssignmentE+0x203)[0x7f9b5347c833]

/~/or-tools/ubuntu-16.04/lib/libortools.so(+0x83e266)[0x7f9b53460266]

/~/or-tools/ubuntu-16.04/lib/libortools.so(+0x83e222)[0x7f9b53460222]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research15FindOneNeighbor4NextEPNS_6SolverE+0x235)[0x7f9b53471a95]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research6Solver12NextSolutionEv+0x235)[0x7f9b533912f5]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research6Solver14SolveAndCommitEPNS_15DecisionBuilderERKSt6vectorIPNS_13SearchMonitorESaIS5_EE+0x2f)[0x7f9b5339259f]

/~/or-tools/ubuntu-16.04/lib/libortools.so(+0x83db0b)[0x7f9b5345fb0b]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research6Solver12NextSolutionEv+0x3ae)[0x7f9b5339146e]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research6Solver5SolveEPNS_15DecisionBuilderERKSt6vectorIPNS_13SearchMonitorESaIS5_EE+0x28)[0x7f9b533919a8]

/~/or-tools/ubuntu-16.04/lib/libortools.so(_ZN19operations_research12RoutingModel33SolveFromAssignmentWithParametersEPKNS_10AssignmentERKNS_23RoutingSearchParametersE+0x206)[0x7f9b534d7d66]

/~/build/Debug/module.node(_ZN19operations_research3Tsp8SolveTspEv+0x17f)[0x7f9b604ea843]

/~/build/Debug/module.node(_Z7ExecuteP10napi_env__Pv+0xbb)[0x7f9b604e84ab]

node[0x1408461]

/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f9b62b076ba]

/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9b6283741d]

Valgrind memcheck log:

==5065== Thread 7:

==5065== Invalid free() / delete / delete[] / realloc()

==5065==    at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

==5065==    by 0xA7B6C7: std::_Hashtable<int, int, std::allocator<int>, std::__detail::_Identity, std::equal_to<int>, std::hash<int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::_M_insert_unique_node(unsigned long, unsigned long, std::__detail::_Hash_node<int, false>*) (in /usr/bin/node)

==5065==    by 0xA333F45: operations_research::PathOperator::InitializePathStarts() (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA33419D: operations_research::PathOperator::InitializeBaseNodes() (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA3343B8: operations_research::PathOperator::OnStart() (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA33D832: operations_research::VarLocalSearchOperator<operations_research::IntVar, long long, operations_research::IntVarLocalSearchHandler>::Start(operations_research::Assignment const*) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA321265: operations_research::(anonymous namespace)::CompoundOperator::MakeNextNeighbor(operations_research::Assignment*, operations_research::Assignment*) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA321221: operations_research::(anonymous namespace)::CompoundOperator::MakeNextNeighbor(operations_research::Assignment*, operations_research::Assignment*) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA332A94: operations_research::FindOneNeighbor::Next(operations_research::Solver*) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA2522F4: operations_research::Solver::NextSolution() (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA25359E: operations_research::Solver::SolveAndCommit(operations_research::DecisionBuilder*, std::vector<operations_research::SearchMonitor*, std::allocator<operations_research::SearchMonitor*> > const&) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA320B0A: operations_research::(anonymous namespace)::NestedSolveDecision::Apply(operations_research::Solver*) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA25246D: operations_research::Solver::NextSolution() (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA2529A7: operations_research::Solver::Solve(operations_research::DecisionBuilder*, std::vector<operations_research::SearchMonitor*, std::allocator<operations_research::SearchMonitor*> > const&) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0xA398D65: operations_research::RoutingModel::SolveFromAssignmentWithParameters(operations_research::Assignment const*, operations_research::RoutingSearchParameters const&) (in /home/jim/docs/platform/modules/tsp/or-tools/ubuntu-16.04/lib/libortools.so)

==5065==    by 0x98DD842: operations_research::Tsp::SolveTsp() (module_tsp.cc:102)

==5065==    by 0x98DB4AA: Execute(napi_env__*, void*) (module.cc:43)

==5065==    by 0x1408460: ??? (in /usr/bin/node)

==5065==    by 0x5AEE6B9: start_thread (pthread_create.c:333)

==5065==    by 0x5E0B41C: clone (clone.S:109)

==5065==  Address 0xb8da720 is on thread 7's stack

==5065==  in frame #2, created by operations_research::PathOperator::InitializePathStarts() (???:)

==5065==

Thanks in advance.

[Jim]

To further clarify,

I am using the routingmodel to solve a travelling salesman problem. On Mac and Windows it all works fine, but on linux I get a memory leak. Yet I only get this with certain specific locations as input. It does not seem to depend on the size of the problem (amount of locations/nodes). When I add certain locations, the program crashes with the errors given above. Could it be that when a routing problem is considered 'difficult' in a certain way by the routingmodel, it calls upon a function (InitializePathStarts) that results in a memory crash on linux?

Op donderdag 19 april 2018 15:04:28 UTC+2 schreef Jim:

[Jim]

Hi,

I managed to track down my issue to the solution pointer. There, something is going wrong. Maybe the InitializePathStarts function then does something which is not allowed. 

The following three commands can all lead to my error:

const Assignment* solution = routing.SolveWithParameters(parameters);

 const Assignment* solution = routing.Solve();

cout << "Total length test solve " << routing.Solve()->ObjectiveValue() << endl;

However, Solve(without parameters) works for a set of locations where SolveWithParameters() fails. Yet it also fails for other sets of locations.

I have not yet been able to figure out what causes a specific set of locations to make the program crash. Things I've ruled out are:

 - large distance between two nodes

 - small distance between two nodes

Does anyone have a clue what is going on here?

Op vrijdag 20 april 2018 11:39:30 UTC+2 schreef Jim:

[Jim]

Hi,

In summary my problem is as follows:

In a node.js C++ module implementation of OR-tools I get a memory issue characterised by:

Error in `node': munmap_chunk(): invalid pointer: 0x00007f9b5240f720

and

Invalid free() / delete / delete[] / realloc()

.

It occurs precisely when I call

 const Assignment* solution = routing.Solve();

, and then seems to go wrong in the following call stack:

std::_Hashtable<int, int, std::allocator<int>

operations_research::PathOperator::InitializePathStarts()

operations_research::PathOperator::InitializeBaseNodes() 

operations_research::PathOperator::OnStart()

operations_research::VarLocalSearchOperator<operations_research::IntVar, long long, operations_research::IntVarLocalSearchHandler>::Start(operations_research::Assignment const*)

 operations_research::(anonymous namespace)::CompoundOperator::MakeNextNeighbor(operations_research::Assignment*, operations_research::Assignment*)

operations_research::(anonymous namespace)::CompoundOperator::MakeNextNeighbor(operations_research::Assignment*, operations_research::Assignment*)

operations_research::FindOneNeighbor::Next(operations_research::Solver*) 

operations_research::Solver::NextSolution()

 operations_research::Solver::SolveAndCommit(operations_research::DecisionBuilder*,

operations_research::(anonymous namespace)::NestedSolveDecision::Apply(operations_research::Solver*) 

 operations_research::Solver::NextSolution()

 operations_research::Solver::Solve(operations_research::DecisionBui

 operations_research::RoutingModel::SolveFromAssignmentWithParameters(operations_research::Assignment const*

 operations_research::Tsp::SolveTsp() 

.

Here, SolveTsp() is the function containing the Tsp solver. It is a member of a Tsp-class object that I call asynchronously from my module, where a pointer to a Tsp object is created, after which its SolveTsp() function is called.

Does anyone know what could be going on here? Thanks in advance.

Op vrijdag 20 april 2018 17:22:14 UTC+2 schreef Jim:

[Jim]

Hi,

Using a different version of the library, the error that gets triggered is:

!!!0[15:52:08] ./ortools/constraint_solver/constraint_solver.h:4948: Check failed: element != nullptrUnknown variable Segmentation fault (core dumped)

Which comes from the following part of code in constraintsolver.h:

    const E& Element(const V* const var) const {

    const E* const element = ElementPtrOrNull(var);

    DCHECK(element != nullptr) << "Unknown variable " << var->DebugString()

                               << " in solution";

    return *element;

  }

Why does this lead to a segmentation fault on Linux?

Op donderdag 19 april 2018 15:04:28 UTC+2 schreef Jim:

Hi,