OpenFlipper-Free issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues2015-12-02T17:37:12Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/22Crash before Main(...)2015-12-02T17:37:12ZGhost UserCrash before Main(...)On my system, a 64bit ArchLinux, OpenFlipper in the head on master-branch does cmake and make without errors, but then when executing it crashes directly with a segfault.
gdb shows the segfault to be before reaching the main(...) method...On my system, a 64bit ArchLinux, OpenFlipper in the head on master-branch does cmake and make without errors, but then when executing it crashes directly with a segfault.
gdb shows the segfault to be before reaching the main(...) method.
A version I pulled a few weeks ago worked on my system up to a recent git pull. Also the version 2.1 of OpenFlipper works.
The error still occurs when I have no additional plugins added.
Following a gdb stack-trace from a run with this segfault.
0 --- ??
1 --- call_init.part
2 --- \_dl\_init
3 --- \_dl\_start\_user
4 --- ??
5 --- ??
6 --- ??
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/56Crash in Script Editor2017-05-04T12:33:26ZHans-Christian EbkeCrash in Script Editor# Steps to Reproduce
1. Start OpenFlipper
2. Menu "Scripting" -> "Show script editor"
3. Inside the script editor, select any entry in the "Function List". (No need to do anything further. Just any entry has to be selected.)
...# Steps to Reproduce
1. Start OpenFlipper
2. Menu "Scripting" -> "Show script editor"
3. Inside the script editor, select any entry in the "Function List". (No need to do anything further. Just any entry has to be selected.)
4. Close the script editor.
5. Menu "Scripting" -> "Show script editor"
6. *CRASH*Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/70Crash when rendering poly lines w/ default internal renderer2017-05-04T12:33:26ZHans-Christian EbkeCrash when rendering poly lines w/ default internal rendererOpenFlipper immediately crashes when displaying poly lines with the default internal renderer. Using the shader pipeline, everything appears to work smoothly.
# Steps to Reproduce
* start OpenFlipper
* set renderer to *Shader Pipe...OpenFlipper immediately crashes when displaying poly lines with the default internal renderer. Using the shader pipeline, everything appears to work smoothly.
# Steps to Reproduce
* start OpenFlipper
* set renderer to *Shader Pipeline*
* open the attached [test.pol](/uploads/ced0dcb7ed7d0f69fcc1209cc9dc0f1f/test.pol)
* the poly line is displayed normally
* switch renderer to *Default Internal*
* *crash*https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/15Create Merge Request for LicenseManager branch2015-11-20T20:35:29ZJan Möbiusmoebius@cs.rwth-aachen.deCreate Merge Request for LicenseManager branchCreate a merge request in gitlab to merge code into masterCreate a merge request in gitlab to merge code into masterOpenFlipper 3.0https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/136Cross-Plugin RTTI / dynamic_cast / OVM properties2020-04-21T13:29:00ZMartin HeistermannCross-Plugin RTTI / dynamic_cast / OVM propertiesOn macOS, dynamic_cast between Plugins is broken, as typeinfo/RTTI is not shared between plugins.
This breaks OVM property lookup, e.g. the PropertyVisualizer cannot access OVM properties created in another plugin, but rather creates its...On macOS, dynamic_cast between Plugins is broken, as typeinfo/RTTI is not shared between plugins.
This breaks OVM property lookup, e.g. the PropertyVisualizer cannot access OVM properties created in another plugin, but rather creates its own uninitialised properties with the same name, because the dynamic_cast on the correct property returns NULL, so it cannot be found. (Side note: maybe an optional request_property bool parameter like `fail_if_missing` would be useful?).
@lyon created a workaround for this by defining `OVM_FORCE_STATIC_CAST`, which will avoid the dynamic_cast, however this is at the cost of type safety and making it impossible to have multiple properties of different types sharing the same name.
I tried to fix this properly by setting a QPluginLoader option (`ExportExternalSymbolsHint`) that exports one plugin's symbols to the other plugins, cf https://www.graphics.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper/tree/fix_plugin_rtti_macos
This nicely fixed the issue on macOS, however I get immediate crashes on startup on Linux, I assume this is due to different things with the same symbol name in multiple Plugins that get mixed up.
Potential solutions:
* ExportExternalSymbolsHint + more appropriate `-fvisibility` settings to avoid Linux issues (leveraging windows dllexport macros?)
* Keeping RTTI info for all types that should be shared between Plugins in main OpenFlipper
* simple hand-rolled RTTI for OVM props to achieve better type safety, e.g. comparing type names from typeid().
* dirty fix: only enable `ExportExternalSymbolsHint` on macOS
Open questions:
* Why does this even work on Linux & Windows? (EDIT: libstdc++ seems to use strcmp based type comparison, cf http://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html - libc++ does not and relies on the linker)
* Which symbol collisions cause the Linux crash?
* How is this done in OpenMesh?https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/168Current 4.0 release does not work with Qt > 5.9 and starts with black screen2020-03-17T16:43:11ZMartin HeistermannCurrent 4.0 release does not work with Qt > 5.9 and starts with black screenThe current 4.0 release still has a long-fixed bug in the cmake scripts that breaks it for Qt > 5.9 (broken regex that assumes 1 character for the minor release number).
The other big issue is #164 that causes users to be greeted with a...The current 4.0 release still has a long-fixed bug in the cmake scripts that breaks it for Qt > 5.9 (broken regex that assumes 1 character for the minor release number).
The other big issue is #164 that causes users to be greeted with a black screen unless they figure out to change the renderer.
Maybe we could have a new release soon?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/43Debug Mode: Mysterious window pops up and stays open.2016-04-28T07:43:40ZHans-Christian EbkeDebug Mode: Mysterious window pops up and stays open.When I start up OpenFlipper after compiling it in debug mode, a weird modal dialog pops up and stays open. See the attached screenshot.
![Mysterious Window](/uploads/89e6e99df3e435ca790f89c310247d6d/Screenshot_from_2016-04-27_19_07_58...When I start up OpenFlipper after compiling it in debug mode, a weird modal dialog pops up and stays open. See the attached screenshot.
![Mysterious Window](/uploads/89e6e99df3e435ca790f89c310247d6d/Screenshot_from_2016-04-27_19_07_58.png)Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/91Deselection of Global Draw Mode when shift-clicking other Draw Mode2017-05-04T14:40:30ZPeter CollienneDeselection of Global Draw Mode when shift-clicking other Draw ModeExample:
The global Draw Mode is set to "solid (colored per face)". Whenever i shift-click on wireframe to also see the wireframe, the global draw mode is deselected and all i see is a wireframe.
Desired Behaviour: Keep the previous glob...Example:
The global Draw Mode is set to "solid (colored per face)". Whenever i shift-click on wireframe to also see the wireframe, the global draw mode is deselected and all i see is a wireframe.
Desired Behaviour: Keep the previous global draw mode and additionaly render using the selected draw mode when shift-clicking a different draw modeOpenFlipper-4.0Jascha WedowskiJascha Wedowskihttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/28Disable Scenegraph Updates While Loading Multiple Files2019-02-07T14:55:35ZHans-Christian EbkeDisable Scenegraph Updates While Loading Multiple FilesIn two situations,
* when loading multiple files via the command line and
* when loading multiple files via the File->Open dialog
scene graph updates should be disabled until the last file is loaded.In two situations,
* when loading multiple files via the command line and
* when loading multiple files via the File->Open dialog
scene graph updates should be disabled until the last file is loaded.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/163Docs: Example Plugins should be tested by CI2019-03-07T20:35:09ZMartin HeistermannDocs: Example Plugins should be tested by CIThe example plugins were broken for various reasons for a long time.
I suggest integrating them into CI so this won't happen again.
Maybe a PluginCollection-Examples that is disabled by default?The example plugins were broken for various reasons for a long time.
I suggest integrating them into CI so this won't happen again.
Maybe a PluginCollection-Examples that is disabled by default?https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/82Draw mode "Solid (colored per vertex, shaded)" actually shows colors per face2017-05-04T12:33:24ZPatrick SchmidtDraw mode "Solid (colored per vertex, shaded)" actually shows colors per faceAfter assigning a color to each vertex and switching to the draw mode "Solid (colored per vertex, shaded)", I see the following:
![per_vertex_shaded](/uploads/04b7915038f5bad44bad7a8e8a3ad37c/per_vertex_shaded.png)
Instead of linearl...After assigning a color to each vertex and switching to the draw mode "Solid (colored per vertex, shaded)", I see the following:
![per_vertex_shaded](/uploads/04b7915038f5bad44bad7a8e8a3ad37c/per_vertex_shaded.png)
Instead of linearly interpolating the vertex colors, constant colors are shown per face.
The non-shaded draw mode "Solid (colored per vertex)" works just fine:
(Exact same colors are used)
![per_vertex](/uploads/48b445750eb49a2a1e2067e244eb862b/per_vertex.png)
In both cases, the shader pipeline renderer was used.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/121Dual Depth Peeling using classic rendering pipeline seems broken2017-07-12T13:52:49ZMartin SchultzDual Depth Peeling using classic rendering pipeline seems broken![Screenshot_20170706_175115](/uploads/15d1a02b97c871f5e5761dc4e39cb718/Screenshot_20170706_175115.png)
The plugin only renders the objects slightly translucent on top of the desktop / previously opened application.
The application in t...![Screenshot_20170706_175115](/uploads/15d1a02b97c871f5e5761dc4e39cb718/Screenshot_20170706_175115.png)
The plugin only renders the objects slightly translucent on top of the desktop / previously opened application.
The application in the background is further updated, e.g. you can watch a movie with the dual depth peeling rendering on tophttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/25EDGE_COLORS outputs wrong color for last edge2015-12-13T18:46:54ZPeter CollienneEDGE_COLORS outputs wrong color for last edgeThe last edge is colored with the color of the first vertex instead of the
color of the last vertex.
The last edge is colored with the color of the first vertex instead of the
color of the last vertex.
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/167Edge property visualization with property visualizer plugin2020-11-20T09:13:02ZNicolas Gallego-OrtizEdge property visualization with property visualizer pluginSystem: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected be...System: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected behavior when visualizing edge properties of meshes (OpenMesh) with the property visualization plugin. I the provided file there is a triangle mesh of a plane, and an edge property saved from it.
I get this error message on the console, and the mesh is rendered as a tube on the z-direction as shown in the image. The plane mesh can be seen after clicking on the object for a short time but the edges shown are not those of the original mesh.
I would be happy to help solve this issue, for now just let me know if you can reproduce it in other systems and some hints on where to start the debugging process.
Thanks,
Nicolas
```
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:650 - 1282
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:704 - 1282 - inColor
```
[mesh2.om](/uploads/7d19640750d0d63bac96123c433397d2/mesh2.om)
[kappa.eprop](/uploads/85cb68a117b9b3876525ecc5ce580307/kappa.eprop)
![screenshot](/uploads/086c07c3b29a4618be864f85cb6e206e/screenshot.png)Nicolas Gallego-OrtizNicolas Gallego-Ortizhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/36Enabling reflections changes global visualisation mode2016-10-20T08:24:20ZMartin SchultzEnabling reflections changes global visualisation modeProblem:
When i enable the reflectiontexture on a mesh the global draw mode is set to solid environment mapped.
Especially if you have multiple meshes in a scene this will cause a lot of confusion as i would not expect the global draw...Problem:
When i enable the reflectiontexture on a mesh the global draw mode is set to solid environment mapped.
Especially if you have multiple meshes in a scene this will cause a lot of confusion as i would not expect the global draw mode to be changed by enabling the reflection texture on one mesh.
Steps to reproduce:
1. load multiple meshes.
2. enable reflection texture on one mesh
3. watch how the other meshes are now displayed as environment mapped.
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/1Environment mapping render mode does not work2016-10-20T08:24:20ZJanis BornEnvironment mapping render mode does not workCurrently, none of the included renderers handles objects with draw mode SOLID_ENV_MAPPED. The Classical / built-in renderer just ignores objects with that draw mode and the Shader Pipeline Renderer just displays a black surface.Currently, none of the included renderers handles objects with draw mode SOLID_ENV_MAPPED. The Classical / built-in renderer just ignores objects with that draw mode and the Shader Pipeline Renderer just displays a black surface.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/157Extend Texture interface to allow adding embedded textures2018-06-05T13:56:58ZMartin SchultzExtend Texture interface to allow adding embedded texturesThe texture interface currently only supports adding textures from explicit image files.
In some scenarios, a texture without a respective filename to load it is required.
(e.g. when embeded textures shall be loaded from a mesh file rela...The texture interface currently only supports adding textures from explicit image files.
In some scenarios, a texture without a respective filename to load it is required.
(e.g. when embeded textures shall be loaded from a mesh file related to https://www.graphics.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/issues/116 )
~~As each texture is stored in the imagestore, a mapping from filename to texture id is used to manage textures. For textures without file backing an alternative could be to use dedicated internal names e.g. by prefixing the filename of file backed textures, so the image store only loads file backed textures, but ignores embedded textures.~~Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/132FAQ is out of date2018-06-19T08:30:30ZMartin SchultzFAQ is out of datethe versions of qt etc are out of date in the faq, it has to be updated.the versions of qt etc are out of date in the faq, it has to be updated.https://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/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.de