Opened 8 years ago

Closed 7 years ago

#17 closed defect (wontfix)

segmentation fault in expression::compare with exprCopy

Reported by: stefan Owned by: somebody
Priority: major Milestone:
Component: component1 Version:
Keywords: Cc:



I get a segmentation fault in expression::compare.

The problem seem to be in the code

 if (c0 >= COU_EXPROP) { // both are exprOp's

    exprOp *ne0 = dynamic_cast <exprOp *> (this);
    exprOp *ne1 = dynamic_cast <exprOp *> (&e1);

    return ne0 -> compare (*ne1);

For some reason, e1 is an exprCopy. e1.code() gives the code of the copy, which seem to be the same as the one of e0. But since e1 has type exprCopy, its address cannot be casted to an exprOp*, giving ne1 = NULL.

Apart from some missing assert statements, this gives a segmentation fault short after.

If I add a print() and e1.print(), I get


(I know this is nonsense, but there seem to be people out there who model such things.)

The gdb backtrace is

(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb7e167af in raise () from /lib/
#2  0xb7e180f0 in abort () from /lib/
#3  0xb7e0f014 in __assert_fail () from /lib/
#4  0xb7769430 in Couenne::expression::compare (this=0x80ffb10, e1=@0x80ff958) at ../../../../Couenne/src/expression/expression.cpp:91
#5  0xb776a28b in Couenne::exprCopy::compare (this=0x80ffcd0, e=@0x80ff958) at ../../../../Couenne/src/expression/CouenneExprCopy.hpp:182
#6  0xb776a28b in Couenne::exprCopy::compare (this=0x80ffce8, e=@0x80ff958) at ../../../../Couenne/src/expression/CouenneExprCopy.hpp:182
#7  0xb776b1f1 in Couenne::exprOp::compare (this=0x80ffbc0, e1=@0x80ff830) at ../../../../Couenne/src/expression/exprOp.cpp:84
#8  0xb776944b in Couenne::expression::compare (this=0x80ffbc0, e1=@0x80ff830) at ../../../../Couenne/src/expression/expression.cpp:93
#9  0xb77785e7 in Couenne::exprSum::exprSum (this=0x80ff8e0, arg0=0x80ffbc0, arg1=0x80ff830) at ../../../../Couenne/src/expression/operators/exprSum.cpp:41

I do not use exprCopy to setup expressions, so it must have been added by Couenne at some point.

This is with Couenne/stable/0.4, but seems to happen with 0.3 too.


Change History (3)

comment:1 Changed 8 years ago by stefan

Short update:

The duplicate entries in max(y_156,y_156,max(y_155,y_155,max(y_154,y_154,max(y_153,y_153,-1e+299,-1e+299),... are due to the way that Couenne handles min and max. When creating an exprMax with 2 arguments, the exprMax constructor creates 4 arguments for it.

The recursive use of max operators and the -1e+299 is due to the way how GAMS handles a max over a set.

Couenne (stable/0.4 rev848) produces a similar segmentation fault when using min instead of max.

comment:2 Changed 8 years ago by pbelotti

These expressions were designed to be a little more flexible than just max {f1(x), f2(x),...}. They are defined with 2k arguments as follows:

y = max {g_1(x), f_1(x), g_2(x), f_2(x), ..., g_k(x), f_k(x)}

where x is the vector of variables. These expressions mean that, given x, if g_i(x) >= g_j(x) for all j!=i, then y=f_i(x). The maximum of a set of functions is then simply given by setting g_i(x) = f_i(x), as in the example provided.

Observe that these expressions are not yet in the set of usable operators of Couenne, because at this point there is no generator of linear inequalities for them.

comment:3 Changed 7 years ago by pbelotti

  • Resolution set to wontfix
  • Status changed from new to closed

Maxima/Minima? of functions are not to be used in formulating problems yet. Closing ticket for now.

Note: See TracTickets for help on using tickets.