Title Segfaults with 32-bit CPLEX build
Priority bug Status chatting
Superseder Nosy List florian, jendrik, malte, silvan
Assigned To Keywords
Optional summary

Created on 2016-11-13.15:23:34 by florian, last changed by silvan.

msg5812 (view) Author: malte Date: 2016-11-14.12:22:46
This is precisely the discussion that I think should not be hidden away in an
issue called "segfaults with 32-bit CPLEX build".
msg5811 (view) Author: florian Date: 2016-11-14.12:19:29
Do we want to actively prevent a 32-bit build? I thought we are just talking
about changing the default?

With cmake we have little control over the bit width. We can detect what it is
at cmake runtime and exit with an error if it is not what what we expected. We
currently do this if we detect a 64 bit build but the option "Yes, I know what
I'm doing. I really want a 64 bit build." is not set. Are you suggesting to do
something like this for the 32 bit build?
msg5810 (view) Author: malte Date: 2016-11-14.10:18:16
I wouldn't wait. People are always in a better position to influence a decision
if they can participate in the process early. Let's avoid a fait accompli situation.

One could argue that everyone had the chance to join issue213 before, but most
of them weren't around when it was opened in 2011, so they got no notification,
and also the title of the issue only suggests improving the 64-bit build, not
getting rid of the 32-bit build.
msg5809 (view) Author: florian Date: 2016-11-14.10:08:06
Issue213 is about the memory usage in the 64bit build. Should we wait with the
announcement on downward-dev until we have some up-to-date data?
msg5808 (view) Author: malte Date: 2016-11-13.15:33:46
I think our best time investment might be to move to 64-bit builds. This would
have the additional advantage of significantly simplifying our build
requirements and infrastructure.

In the last tests we made, 64-bit builds already tended to be faster than 32-bit
builds, but memory usage was an issue. Since that time our data structures and
compiler versions have changed a lot, I think. So we definitely need more tests.
These should cover a broad spectrum of search algorithms and heuristics.

If you agree that this is a reasonable goal to pursue, I think we should open a
new issue for this and announce it to downward-dev because it is a rather
high-level change.
msg5807 (view) Author: florian Date: 2016-11-13.15:23:34
We have seen segfaults with 32-bit CPLEX on several computers even when just
building a small CPLEX test program. After some tests, I suspect that this is
caused by a bug in CPLEX that shows up in combination with newer binutils
versions. With the binutils from Ubuntu 16.10 linking the sample code
dynamically fails and complains about the cplex library (direct GOT relocation
R_386_GOT32 against `UCNV_FROM_U_CALLBACK_STOP_44_cplex' without base register
can not be used when making a shared object). Older versions do not detect this
and then crash at runtime.

It is unlikely that IBM will fix this in the old version. Newer versions of
CPLEX (>= 12.7) no longer support 32-bit builds. We can currently still run
experiments with CPLEX on the grid because they still have an old enough version
of binutils, but in the long run, we probably have to switch to 64 bit.

I opened this issue mainly so we can discuss how to handle this.

For reference, here it the discussion in the IBM forum:
Date User Action Args
2016-11-14 15:10:15silvansetnosy: + silvan
2016-11-14 12:22:46maltesetmessages: + msg5812
2016-11-14 12:19:29floriansetmessages: + msg5811
2016-11-14 10:18:16maltesetmessages: + msg5810
2016-11-14 10:08:06floriansetmessages: + msg5809
2016-11-13 15:33:46maltesetstatus: unread -> chatting
messages: + msg5808
2016-11-13 15:23:34floriancreate