Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault with Boost => 1.69 #1506

Closed
H27CK opened this issue Apr 7, 2020 · 2 comments
Closed

Segfault with Boost => 1.69 #1506

H27CK opened this issue Apr 7, 2020 · 2 comments
Assignees
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: High Should be handled next T: Bug Wrong statements in the code or documentation

Comments

@H27CK
Copy link

H27CK commented Apr 7, 2020

We (@jarsi, @jasperalbers) see consistent segmentation faults when sorting presynaptic connections using Boost =>1.69 (no segfault with v1.68, but versions 1.69 and 1.70 are seemingly incompatible) on multiple HPC systems (JURECA and DEEP-EST), running a variety of cases (HPC benchmark, microcircuit, multi-area model). It is necessary to confirm the issue on other systems with Boost => 1.69.

In libnestutil/sort.h,

sort( BlockVector< T1 >& vec_sort, BlockVector< T2 >& vec_perm )

is confirmed to contain the problematic code:

boost::sort::spreadsort::integer_sort( make_iterator_pair( vec_sort.begin(), vec_perm.begin() ), make_iterator_pair( vec_sort.end(), vec_perm.end() ), rightshift_iterator_pair() );.

Forcing quicksort3way(), even if HAVE_BOOST is defined, i.e. always using

quicksort3way( vec_sort, vec_perm, 0, vec_sort.size() - 1 );,

resolves the issue; this change only serves to confirm the issue. We believe the problem to be caused by changes in Boost >1.68 which have introduced some incompatibility, most likely in:

boost/sort/spreadsort/spreadsort.hpp
boost/iterator/iterator_adaptor.hpp
boost/tuple/tuple.hpp

Recommendations: since NEST seems to only make use of Boost here, we suggest to drop Boost completely and replicate the desired functionality. Reasons:

  1. the list of dependencies is reduced;
  2. it is excessive to build and maintain a complete Boost installation for this functionality;
  3. we ensure that similar issues do not occur with future versions of Boost;
  4. it is not clear to some users how NEST benefits from Boost - it is ignored as an (optional) dependency; we can guarantee that all users benefit from enhanced sort if implemented in NEST.
@H27CK
Copy link
Author

H27CK commented Apr 7, 2020

I have been pointed to #1502. We will look into this first. This issue may be redundant.

@terhorstd terhorstd added I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: High Should be handled next T: Bug Wrong statements in the code or documentation labels Apr 7, 2020
@H27CK
Copy link
Author

H27CK commented Apr 7, 2020

The changes in #1502 remedy this issue. However, to eliminate Boost as a dependency (even if header-only), it is still our opinion that the desired functionality should be implemented directly in NEST . If that is not possible, then Boost should be enabled by default, as suggested in #1477.

@H27CK H27CK closed this as completed Apr 7, 2020
@jessica-mitchell jessica-mitchell moved this to Done in Kernel Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: High Should be handled next T: Bug Wrong statements in the code or documentation
Projects
Status: Done
Development

No branches or pull requests

3 participants