coin-or
CBC 2.10.6 crashing: fabs(floor(value + 0.5) - value) <= integerTolerance
I am using CBC 2.10.5 from Debian Stable (bullseye) and have a problem which crashes CBC very quickly.
Welcome to the CBC MILP Solver
Version: 2.10.5
Build Date: Oct 15 2020
command line - cbc tmpllxn1txy.pyomo.lp (default strategy 1)
Continuous objective value is 100 - 0.00 seconds
Cgl0003I 0 fixed, 5 tightened bounds, 6 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 1 tightened bounds, 2 strengthened rows, 1 substitutions
Cgl0003I 0 fixed, 0 tightened bounds, 1 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 0 tightened bounds, 1 strengthened rows, 0 substitutions
Cgl0004I processed model has 36 rows, 27 columns (27 integer (14 of which binary)) and 134 elements
Cutoff increment increased from 1e-05 to 0.4999
Cbc0038I Initial state - 4 integers unsatisfied sum - 0.599799
Cbc0038I Pass 1: suminf. 0.40221 (3) obj. 100.301 iterations 11
cbc: CbcHeuristic.cpp:2641: virtual int CbcRounding::solution(double&, double*, double): Assertion `fabs(floor(value + 0.5) - value) <= integerTolerance' failed.
Aborted
The problem is available here: https://gist.github.com/public/ba9c11a4dde6dafcf55f1a927df8f6b5
This same problem works fine in 2.9.9
You'll note in the command line that I am not even passing -solve here but it also crashes if I do. Turning the feasibility pump off seems to get it working again but that also seems like a useful feature to have.
What is very odd about this bug is that it is an assert failing which is an #ifndef NDEBUG. When I build a non debug version of Cbc NDEBUG is defined in all Makefiles so the assert should not be compiled.
Without the assert the code would not fail - the heuristic might provide a bad solution, but that would be thrown out on later checks. It looks as if CBC 2.10.5 from Debian Stable (bullseye) was compiled with debug!
The error occurs because an integer variable had a very small infeasibility (i.e. a small negative value when bounds are 0-1) and the heuristic got confused.
I have updated stable
I've reported it to Debian here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001264
I'm the maintainer for the Debian package of coinor-cbc ; I don't think I do anything to enable asserts...
Or perhaps they are enabled by default and I should do something to disable them?
Hmm interesting, I had someone report line number information from valgrind to me when they were debugging another COIN-OR project on Debian and I was also wondering at that time how they had line number information unless the code was compiled with debugging enabled!
After trying quite a bit, I couldn't easily find exactly how the build recipe is specified, but I did finally (I think) find the output from a build, e.g., here:
https://buildd.debian.org/status/fetch.php?pkg=coinor-cbc&arch=ia64&ver=2.10.5%2bds1-3&stamp=1602754349&raw=0
It seems that the configure script is re-generated with autoreconf, which probably plays havoc with the build system. I don't really know what it's doing or how it even works, given that this version of Cbc has some m4 that only works with a very old version of autoconf. Maybe old versions of autoconf are available on the build machine just in case? Anyway, afterwards, the default compiler flags generated by configure seem to be completely changed or else they are over-ridden. The options passed to the compiler finally are
-g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security
Weird. I have no idea really where the -g comes from. I can't replicate it because the configure script is a completely different one than we have checked in. If I run configure with exactly the same siwtches, I don't get the -g, I get reasonable flags.
Re-generating the configure script seems like it might not be a great idea, since all of our testing and debugging is done with the fixed configure script that we very intentionally release with the code to be used exactly as is. Changing it makes it hard to debug things like this.
@SnarkBoojum I don't mean to dump all over your efforts, which are greatly appreciated! This may be standard procedure and out of your control. I can help dig if you can give me a little more information about how to replicate. Is it possible to disable the autoreconf?
Well, the real source file is configure.ac, so of course configure gets rebuilt... The autotools way is:
- devs use configure.ac and depend on all autotools, and do their thing ;
- when publishing the sources, then configure gets generated so users don't need autotools to build the software.
The flags with -W are there because Debian pushes for higher code quality ; the -fdebug-prefix-map is certainly there to go with -g for the same reason, but it probably wouldn't be there if there was no -g. So the question is: why -g ?
I'll look into this as soon as I'll be able to compile 2.10.6, and that's #474.
Well, the real source file is configure.ac, so of course configure gets rebuilt... The autotools way is:
- devs use configure.ac and depend on all autotools, and do their thing ;
- when publishing the sources, then configure gets generated so users don't need autotools to build the software.
Yes, exactly, but we do the step of re-generating configure before making the release, so that packagers like you don't have to do that again. Re-generating with the required version of the autotools won't result in any change.
What makes the situation complicated is that we got pegged to this very old version of autoconf after we monkey-patched some stuff in libtool ourselves to work around some bugs. The autotools moved on, but we lost some developers and didn't have the bandwidth to unwind all of the monkey-patching to get back in step with the latest autotools. That's finally all been done and the next major version of Cbc won't have this issue, but with 2.10, we are still stuck with this old version of our build tools. I'll say some more in #474.
This problem also appears to occur with the statically built CBC binaries from AMPL.
e..g. I sometimes get errors such as
cbc: /tmp/coin/Cbc/Clp/src/ClpNonLinearCost.cpp:1064: void ClpNonLinearCost::checkInfeasibilities(double): Assertion lowerValue <= upperValue' failed.
I was unable to reproduce 2.10.6 crashing - because it does not - it was 2.10.5 as mentioned in original report. The bug was fixed in 2.10.6.
However if the assert was not there or code compiled in optimized mode, then the problem goes away as maybe a bad solution would be generated but discarded by heuristic. Using these executables, I noticed great variations in speed.
Doing some timings on my laptop for - cbc -dirmiplib .../miplib3 -miplib (elapsed approximately same as cpu unless otherwise mentioned)
ampl cbc 10:31 debian cbc 3:58 elapsed 4:36 cpu 10.6 cbc debug noopts 6:13 elapsed 7:35 cpu 10.6 cbc debug sensible 5:47 10.6 cbc optimized 1:59
By default cbc picks up threaded blas which is not a good idea - the sensible versions switch that off, use openblas library and add
ADD_CXXFLAGS="-DCLP_USE_OPENBLAS=1" LDFLAGS="-lopenblas -lpthread -lrt"
to configure
On 03/02/2022 15:33, Alex Stapleton wrote:
This problem also appears to occur with the statically built CBC binaries from AMPL.
— Reply to this email directly, view it on GitHub https://github.com/coin-or/Cbc/issues/462#issuecomment-1029111693, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWJYHFY3GDI4XTBVNDDNITUZKN3VANCNFSM5JOZK2LQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
The pre-built AMPL libraries I am using are also 2.10.5. They were downloaded from https://ampl.com/dl/open/cbc/cbc-linux64.zip earlier this week and have the SHA-256 ee9781c0e2820066de78416edb22ca2041e98766cd47776d187c3555b844e64e.
Edit: Getting a bit off topic but how are the versions on GitHub compiled? They don't seem to support -threads? They do at least seem to have debugging disabled but they link to libblas not openblas.