Originally posted by: JorisK

Dear,

When I run the attached CPO model through the attached CPOFileReader, Java crashes with the message "A fatal error has been detected by the Java Runtime Environment" (see attached core dump). The error is probably caused by some error in the CPO file, but I don't think this should result in a crash, instead of a more graceful error. The CPO model is solved using CP optimizer v.12.6.2.

Update: uploaded much smaller CPO model with the same issue.

br,

Joris

Originally posted by: ChrisBr

Hello Joris,

We need a little more information:
How was this .cpo generated? (which instruction? which lib's version? did you modify it? ...)
Sorry for the disturbance but the most precise information we'll get, and the better help we'll be able to provide.

Regards,

Chris.

Originally posted by: JorisK

Hi Chris,

I hapilly provide all the necessary information (I'm rather stuck with my own implementation as I cannot figure out what's going wrong).

1. The CP model is built in Java through the concert interface. The .cpo model is generated using the cp.exportModel("model.cpo") command.

2. I'm using the default IBM ILOG CPLEX Optimization Studio 12.6.2 (Linux 64-bit version), no modifications or custom lib's. 

3. Although probably not very relevant, I'm running java version "1.8.0_60".

Were you able to replicate the issue?

In the CPO file there is just a single type  of constraints, generated as follows:

cp.add(
        cp.eq(
                cp.element(fuel, succ[i]),
                cp.diff(
                        fuel[i],
                        cp.element(fuelConsumptionVector,
                                cp.sum(cp.constant(i * n * nrOfVehicles), cp.prod(succ[i], nrOfVehicles), vehicleVar[i])
                        )
                )
        )
);

The 2 large vectors in the CPO model are identical.

Update: The problem also occurs with IBM ILOG CPLEX Optimization Studio 12.6.1 (Linux 64-bit version) 

Originally posted by: Petr Vilím

Hello Joris,

indeed there is a bug. I'm not sure yet where exactly it is but we're working on a fix. Thanks for letting us know!

In the meantime there is a workaround: do not use an expression as an index in element. Use a variable instead. The variable can be bound to the value of the expression.

Cheers, Petr

Originally posted by: JorisK

Great, thanks Petr! I'll give the workaround a try.

Joris

Ps. Are you coming to informs next week? 

Originally posted by: Petr Vilím

Hello Joris,

no, I will no go to Informs..

I fixed the bug, the fix will be in the next release.

Thanks again for the report and enjoy Informs!

Petr

Originally posted by: JorisK

Hi Petr,

Is there a way to obtain an early version of the upcoming CP optimizer (12.6.3) where this particular problem is fixed? Rewriting the model using the work-around you sketched would involve quite some work, so it would be great if there's some (stable) version available.

Joris

Originally posted by: JorisK

Hi Petr,

The workaround suggested by you:

In the meantime there is a workaround: do not use an expression as an index in element. Use a variable instead. The variable can be bound to the value of the expression.

doesn't seem to work :(. I've updated the example (see file attached). This still seems to crash, on the same system. Any suggestions as to what I could do? I'm running into trouble with a conference deadline at the moment, so any workaround is appreciated.

Thanks,

Joris

Originally posted by: JorisK

Here's another (different) crash result which may or may not be related to the same error. When running the attached file I get this obscure error. Never seen it before, but according to Google: "The code frees memory that is not or no longer valid. That means either the address is wrong, because for example of pointer arithmetic being done on the original pointer. Or the pointer has already been freed (double free)."

Error:

*** glibc detected *** java: free(): invalid next size (fast): 0x00007f0f30015710 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7db26)[0x7f0fa54a5b26]
/opt/ILOG/CPLEX_Studio1262/opl/bin/x86-64_linux/libopl1262.so(_ZN11IlcCPOStackD2Ev+0x27)[0x7f0f5a674917]
/opt/ILOG/CPLEX_Studio1262/opl/bin/x86-64_linux/libopl1262.so(_ZN14IlcCPOManagerID1Ev+0xe8)[0x7f0f5a638ad8]
/opt/ILOG/CPLEX_Studio1262/opl/bin/x86-64_linux/libopl1262.so(_ZN6IloCPID0Ev+0x5c5)[0x7f0f5a4610f5]
/opt/ILOG/CPLEX_Studio1262/opl/bin/x86-64_linux/libopl1262.so(_ZN12IloAlgorithm3endEv+0x12)[0x7f0f59fbc146]
...

The CPO file causing this result is attached. Same machine as before. The previous bug reports caused the Java JVM to crash. This however seems to be something else.

Originally posted by: Petr Vilím

We exchanged a few emails with Joris. For the readers of the forum, here is a short summary.

It is still the same bug. It will be fixed in the next release. In the meantime in order to avoid the bug, it is necessary to use element expressions only with variables: the index parameter should be a variable (not an expression) and the result of the element should be also compared with a variable, not an expression.

I.e. all constraints in a form:

expressionA == element(expressionB, values);

should be converted to:

indexVar == expressionB;
resultVar == element(indexVar, values);
expressionA == resultVar;

In order to simplify the work, I suggest to create a function, e.g. "elementWorkaround", that creates the necessary auxiliary variables locally. Then just use "elementWorkaround" instead of "element".

Note that most of the time element expression works well. The problem happens only if expressionA or expressionB have some special feature. It is hard to specify exactly what the feature is because presolve often rewrites the expressions. So I don't suggest to apply the workaround unless you think that you're hit by the bug.

Petr