OR crashes when exiting after selecting a violation

[titan73]

Describe the bug

As title says. More info below.

Expected Behavior

Not crash at the end.

Environment

OpenROAD v2.0-16968-g223313baf

To Reproduce

To reproduce:

• extract test case below drc_blink.zip
• cd to folder
• openroad -gui
• open test.odb from menu
• load violations.drc
• expand "short" tree
• click on first violation
• exit openroad

Relevant log output

OpenROAD v2.0-16968-g223313baf 
Features included (+) or not (-): +Charts +GPU +GUI +Python
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
[WARNING GUI-0077] Timing data is not stored in /home/costa/stusb/rtl2gds/unicad/libre/drc_blink/test.odb and must be loaded separately, if needed.
Signal 11 received
Stack trace:
 0# 0x000059208B0364E5 in /home/costa/OpenROAD/build/src/openroad
 1# 0x000078FF63A42520 in /lib/x86_64-linux-gnu/libc.so.6
 2# std::_Rb_tree_increment(std::_Rb_tree_node_base const*) in /lib/x86_64-linux-gnu/libstdc++.so.6
 3# gui::RenderThread::drawBlock(QPainter*, odb::dbBlock*, odb::Rect const&, int) in /home/costa/OpenROAD/build/src/openroad
 4# gui::RenderThread::draw(QImage&, QRect const&, std::set<gui::Selected, std::less<gui::Selected>, std::allocator<gui::Selected> > const&, std::array<std::set<gui::Selected, std::less<gui::Selected>, std::allocator<gui::Selected> >, 8ul> const&, std::vector<std::unique_ptr<gui::Ruler, std::default_delete<gui::Ruler> >, std::allocator<std::unique_ptr<gui::Ruler, std::default_delete<gui::Ruler> > > > const&, double, QColor const&) in /home/costa/OpenROAD/build/src/openroad
 5# gui::RenderThread::run() in /home/costa/OpenROAD/build/src/openroad
 6# 0x000078FF648CCCA1 in /lib/x86_64-linux-gnu/libQt5Core.so.5
 7# 0x000078FF63A94AC3 in /lib/x86_64-linux-gnu/libc.so.6
 8# 0x000078FF63B26850 in /lib/x86_64-linux-gnu/libc.so.6
Segmentation fault (core dumped)

Screenshots

No response

Additional Context

No response

[maliberty]

I tried it but got no crash with the head of master (commit 73c1f49)

[gadfort]

@titan73 this fault looks familiar to me, I suspect the exit is called while the search rtree is getting built or getting accessed by the render thread after the main thread has destroyed the search trees. (incredibly hard to replicate due to the temporal dependency).