OpenFlipper-Free issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues2022-05-25T14:13:01Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/182File loading race condition leads to crashes2022-05-25T14:13:01ZMartin HeistermannFile loading race condition leads to crashes[Update 2022-05-25: added more details to clarify the race]
1. A file loading operation calls the plugins's `load()` function called in a new thread
1. `load()` uses `addEmptyObject()` is used to create an object to hold the loaded file...[Update 2022-05-25: added more details to clarify the race]
1. A file loading operation calls the plugins's `load()` function called in a new thread
1. `load()` uses `addEmptyObject()` is used to create an object to hold the loaded file.
1. This emits the `emptyObjectAdded` signal, which is connected to `Core::slotEmptyObjectAdded`
1. `Core::slotEmptyObjectAdded` emits `signalObjectUpdated(_id)` and `signalObjectUpdated(_id, UPDATE_ALL)`
Now these two things can happen in parallel:
- In the loading thread, file loading (e.g. OM or OVM) occurs
- Other plugins get notified vis `slotObjectUpdated` and can operate on this unfinished object at the same time
In particular, `PropertyVisPlugin::slotObjectUpdated` does cause crashes for me, but likely is not the only problematic plugin.
With OM, this can lead to a crash while properties are loaded from the file with the following order of execution:
- Main thread, propvis' `OMPropertyModel<...>::gatherProperties()` calls `mesh_->fprops_begin()`
- File load thread: `OpenMesh::PropertyCreator::create_property()`, this invalidates the fprops_begin iterator
- Main thread: The Property iterator is dereferenced -> crash
I attached the output of an ASAN instrumented build that runs into this with detailed backtraces:
[of-load-om-race-condition-asan-output.txt](/uploads/1621a94f55aea9a81e8dab0596e5bc21/of-load-om-race-condition-asan-output.txt)
How should we go about solving this? Maybe just putting a mutex around mesh access from objects? This would also prevent similar issues when performing mesh processing in a worker thread.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/185Feature edge rendering broken in colored-edges rendering2023-03-17T09:15:30ZMartin HeistermannFeature edge rendering broken in colored-edges renderingWhen visualizing an edge property using edge colors on a mesh that also has feature edges, feature edges are drawn randomly across the space, not even along mesh edges. Every time I click "Visualize" in propvis, the random mess changes, ...When visualizing an edge property using edge colors on a mesh that also has feature edges, feature edges are drawn randomly across the space, not even along mesh edges. Every time I click "Visualize" in propvis, the random mess changes, so I'd guess uninitialized memory - however once in a blue moon, I actually get a rendering that looks like I would expect.
![bad](/uploads/166aacb87d04eada58431db4315b4544/fail.png)
![good](/uploads/c281f02da8ab6c9eba05339210aff37a/ok.png)
Btw, a while ago, I had fixed (or maybe not entirely fixed :/) some bug with similar symptoms, I wouldn't be surprised if this is in similar code paths:
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper/-/merge_requests/188Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/186Build issue: System-wide install of pybind11 interferes2024-02-05T12:34:09ZMartin HeistermannBuild issue: System-wide install of pybind11 interferesHi, my system has pybind11 installed in a global include dir, which apparently takes precedence over the local copy of pybind11.
It leads to this sort of compile error:
```
[...]
In file included from /Users/mh/src/OpenFlipper-IGM/OpenFl...Hi, my system has pybind11 installed in a global include dir, which apparently takes precedence over the local copy of pybind11.
It leads to this sort of compile error:
```
[...]
In file included from /Users/mh/src/OpenFlipper-IGM/OpenFlipper/PythonInterpreter/PyLogHook.h:32:
In file included from /opt/homebrew/include/pybind11/pybind11.h:13:
[...]
In file included from /opt/homebrew/include/pybind11/detail/../attr.h:13:
/opt/homebrew/include/pybind11/detail/common.h:479:16: error: redefinition of 'ssize_t_cast'
inline ssize_t ssize_t_cast(const IntType &val) {
^
/Users/mh/src/OpenFlipper-IGM/OpenFlipper/libs_required/ACG/../pybind11/include/pybind11/detail/common.h:483:16: note: previous definition is here
inline ssize_t ssize_t_cast(const IntType &val) {
```
## Why does it happen - include folder precedence
At least with gcc and clang, the specified include dirs have left-to-right preference, i.e., earlier has precedence.
The corresponding commandline includes ` -isystem /opt/homebrew/include `, and later `-isystem /Users/mh/src/OpenFlipper-IGM/OpenFlipper/libs_required/pybind11/include`. Folders specified by `-I` take precedence, which is probably what we would like to use for the vendored copy of pybind11.
The cause for CMake to use `-i system` instead of `-I` is the combination of
```
# Check if pybind11 is being used directly or via add_subdirectory
if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
[...]
else()
set(PYBIND11_MASTER_PROJECT OFF)
set(pybind11_system SYSTEM)
endif()
```
and
```
target_include_directories(
pybind11_headers ${pybind11_system} INTERFACE $<BUILD_INTERFACE:${pybind11_INCLUDE_DIR}>
```
in `OpenFlipper/libs_required/pybind11/CMakeLists.txt`.
## Fix?
Patching that file to just `set(pybind11_system "")` results in a successful build for me, but I'm not certain this is the best kind of fix.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.de