arachne-pnr crashes when compiled with _GLIBCXX_ASSERTIONS

[aimylios]

As the version of arachne-pnr available in the Fedora 28 repositories is relatively old (June 2017), I have prepared my own RPM of the current git head for personal use.

Unfortunately it crashes when routing the rot example. This is the backtrace I get:

#0  0x00007ffff710ffeb in raise () from /lib64/libc.so.6
#1  0x00007ffff70fa5c1 in abort () from /lib64/libc.so.6
#2  0x000000000042f758 in std::__replacement_assert (__file=__file@entry=0x4838a0 "/usr/include/c++/8/bits/stl_vector.h", __line=__line@entry=932, 
    __function=__function@entry=0x48af00 <std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >::operator[](unsigned long)::__PRETTY_FUNCTION__> "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = std::pair<int, int>; _Alloc = std::allocator<std::pair<int, int> >; std::vecto"..., 
    __condition=__condition@entry=0x483870 "__builtin_expect(__n < this->size(), true)") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#3  0x000000000044f762 in std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >::operator[] (__n=<optimized out>, this=0x7fffffffc390) at /usr/include/c++/8/new:169
#4  PriorityQ<std::pair<int, int>, Comp>::push (x=..., this=0x7fffffffc388) at src/priorityq.hh:46
#5  Router::visit (this=this@entry=0x7fffffffc0d0, cn=17578) at src/route.cc:601
#6  0x000000000044f932 in Router::start (this=this@entry=0x7fffffffc0d0, net=net@entry=0) at src/route.cc:541
#7  0x0000000000457a94 in Router::route() () at src/route.cc:793
#8  0x00000000004591e4 in route(DesignState&, int) () at src/route.cc:980
#9  0x000000000040eb33 in main () at src/arachne-pnr.cc:637
#10 0x00007ffff70fc24b in __libc_start_main () from /lib64/libc.so.6
#11 0x000000000041165a in _start () at src/arachne-pnr.cc:677

Apparently, this is a well known problem of Fedora 28 and affects a lot of applications. The reason is that some hardenig flags were enabled by default, including _GLIBCXX_ASSERTIONS [1]. This flag "enables extra error checking in the form of precondition assertions, such as bounds checking in strings and null pointer checks when dereferencing smart pointers." [2].

The backtrace points to line 46 in src/priorityq.hh:

 std::push_heap(&v[0], &v[n], comp);

An analysis of this issue and some hints how to handle it are available in the httpuv bug tracker [3]. Maybe this can help you to fix the bug.

[1] https://fedoraproject.org/wiki/Changes/HardeningFlags28
[2] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html
[3] rstudio/httpuv#133 (comment)

[jburgess777]

PR #132 fixes the crash for me.

I have a fork of the Fedora spec file which builds the latest code and this patch but it is blocked until icestorm is updated to add 5k chip support: https://github.com/jburgess777/rpms-arachne-pnr/tree/update-latest