incorrect cheksum problem with Gurobi

[Ian Herszterg]

Hello everybody,

I am having a rather weird problem with Gurobi in c++. I'm running a code that iteratively solves a model, always adding and removing constraints at each iteration. The pseudo code is like:

while( stopping criterion )

model.optimize

if( obj value > xx )

  model.addConstr( ..... )

else if ( ..... )

   model.removeConstr( ... )

   model.addConstr( ... )

model.update

model.optimize

if( obj valie < yy )

 stop

something like that. The code usually runs without any problem, but some times it crashes with the message INCORRECT CHECKSUM when either updating the model or optimizing it, it's very random. To be more precise, this is a snippet of the code:

/* Modifies model */
GRBConstr obj1Constraint = model.getConstrByName("Obj_1");
model.remove( obj1Constraint );
model.addConstr( obj1LineExpression <= 0, "Obj_1" );
model.setObjective( obj2LineExpression, GRB_MINIMIZE );

model.update();
model.optimize();
p2.y = model.get( GRB_DoubleAttr_ObjVal );

I would this happens 3/10 times with a same instance in a same environment. Also, in even more rare occasions, the "model.remove( obj1Constraint ); " fails, saying that the constraint is not in the model. Im running Gurobi 6.5.2 on both a Mac OS X 10.12.2 as my personal computer and a Linux machine where I am conducting my tests. Sometimes when this happens in Linux, I get a huge error like this:

7fc40c000000-7fc40c637000 rw-p 00000000 00:00 0
7fc40c637000-7fc410000000 ---p 00000000 00:00 0
7fc410000000-7fc41069a000 rw-p 00000000 00:00 0
7fc41069a000-7fc414000000 ---p 00000000 00:00 0
7fc414000000-7fc4144bc000 rw-p 00000000 00:00 0
7fc4144bc000-7fc418000000 ---p 00000000 00:00 0
7fc418000000-7fc41870f000 rw-p 00000000 00:00 0
7fc41870f000-7fc41c000000 ---p 00000000 00:00 0 Aborted

which I really don't understand. The abort is happening inside the gurobi library. What could be the cause of this problem? Does anyone have any idea? 

Thank you very much for any help!

[Tobias Achterberg]

This is strange. There is no such error message in the Gurobi code. It must come
from somewhere else. Maybe your code writes into memory it does not own? You
could try valgrind to debug. Or you have a hardware issue? Maybe your RAM?

Regards,

Tobias

[Ian Herszterg]

Hi Tobias, thanks for your answer.

I don't think it's a hardware issue since both my personal computer and the cluster machine are getting the same error. Regarding writing into memory that my code doesn't own, as I said i'm always removing/adding constraints to the model and re-optmizing it. Should I always delete the model and build a new one? This could have a severe impact in performance since most of the instances have a large number of variables and constraints. 

Is there any "auto cleaning" procedure that Gurobi does after solving a model? If so, is there anyway to disable it?

[Tobias Achterberg]

Removing and adding constraints should be fine. There is no need to build the
model from scratch.

There is no "auto cleaning" procedure in Gurobi.

You should try to reproduce the issue with the record/replay feature of Gurobi.
This way you can check whether the issue is in your code or whether it is solely
inside Gurobi. See
http://www.gurobi.com/documentation/7.0/refman/recording_api_calls.html for details.

Regards,

Tobias

[Ian Herszterg]

I'll try using this feature, thanks!

By the way I just got the abort here in the following part of the code:

/* Modifies model */
model.remove( obj1Constraint );
model.addConstr( obj2LineExpression <= p2.y + rhs_tol, "Obj_2" );
model.setObjective( obj1LineExpression, GRB_MINIMIZE );
model.update();
----> model.optimize();

The error message was: malloc: *** error for object 0x100604cf8: incorrect checksum for freed object - object was probably modified after being freed.

Now, the interesting thing is that I am not dynamically allocating anything. The "model" variable is a local variable, I'm not using pointers. Sometimes, the same error occurs in model.update()