But isn’t the old way more strange? (Creating a new mesh inside of netgen which is used outside the library.) When should the mesh be deleted?
Why not create an instance of the mesh inside of smesh netgen-plugin? something like this:
I have tried to un-un-comment the line you have mentioned. No crash but also no mesh.
Could it be that the pointer used in smesh netgen plugin is still a Nullptr?
Could it be that the pointer used in smesh netgen plugin is still a Nullptr?
Unlikely. What I can imagine is that netgen itself is broken and never fills up the mesh or that an non-empty mesh is replaced with an empty mesh somewhere in the smesh sources.
Hmm, but have a look at this example: creating a shared pointer with std::make_shared seems to create not only a new instance but also a new raw-pointer.
#include <memory>
#include <iostream>
class A
{
};
int main()
{
A* a;
a = NULL;
std::shared_ptr<A> a_ptr(a, [](A*){});
a_ptr = std::make_shared<A>();
std::cout << (a_ptr.get() == a) << ", " << (a == NULL) << std::endl;
return 0;
}
#0 0x00007ffff3d28418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff3d2a01a in __GI_abort () at abort.c:89
#2 0x00007ffff3d6a72a in __libc_message (do_abort=2, fmt=fmt@entry=0x7ffff3e836b0 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff3d749be in malloc_printerr (ar_ptr=0x7ffff40b6b20 <main_arena>, ptr=0x2ab2a50, str=0x7ffff3e8051f "malloc(): memory corruption",
action=<optimized out>) at malloc.c:5007
#4 _int_malloc (av=av@entry=0x7ffff40b6b20 <main_arena>, bytes=bytes@entry=184) at malloc.c:3475
#5 0x00007ffff3d765a4 in __GI___libc_malloc (bytes=184) at malloc.c:2914
#6 0x00007ffff4360be8 in operator new(unsigned long) () from /home/lo/anaconda/envs/fc_2/bin/../lib/libstdc++.so.6
#7 0x00007fff5c506aff in netgen::Mesh::Mesh (this=0x2ab26e0)
at /home/lo/anaconda/conda-bld/._1473527418209/work/libsrc/meshing/meshclass.cpp:31
#8 0x00007fff5e4ecd23 in NETGENPlugin_Mesher::Compute (this=0x7fffffff9570) from /home/lo/anaconda/envs/fc_2/lib/./libNETGENPlugin.so
#9 0x00007fff5e5212c0 in NETGENPlugin_NETGEN_2D::Compute (this=0x2815220, aMesh=..., aShape=...)
from /home/lo/anaconda/envs/fc_2/lib/./libNETGENPlugin.so
In the meanwhile I have uploaded a new conda-freecad package with all the new stuff: https://anaconda.org/freecad/freecad
There is one problem that some libraries are used from the distro. And if a distro uses a too old libstdc library the conda approach won’t work. So for example debian jessie wasn’t working the last time I have tried this. A solution could be to use an older distro (eg. debian jessie) to compile freecad…
version info for the current freecad conda package:
OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.8432 (Git)
Build type: Release
Branch: netgen6.1_interface
Hash: 6a962c9bc686ff970ede0ceac9b3423227ede236
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
I have tried this too, but disabling the gui wasn’t working for me. (Linking errors, or something like this) I had the feeling that disabling the gui isn’t really tested.
the linux conda packages are now created with a virgin ubuntu 14.04 and should run on most linux version. Tested are 14.04, 16.04, arch. Still looking for testers on other platforms…
as the python3 branch from yorik was currently updated, and hopefully get merged soon I have tried to get into building this branch. Python3 still make some troubles, but the python2 builds from the python3 branch is also available on conda (package:freecad_py3 but build with py2)
conda-forge will make python3.5 pyside windows builds available: (https://github.com/conda-forge/qt-feedstock/issues/6). This are very good news for us as it will solve some problems with python and windows. Also it makes the port to python3 not dependent on pyside2/qt5. And current problems with netgen should be solved with the python3 port…
Started with windows builds. But I need help with this. Maybe some one familiar with building latest source with vtk7 occt7 on windows could help with this. Trying to build occt7 (https://github.com/looooo/FreeCAD_Conda/blob/master/occt/bld.bat) failed with this error:
CMake Error at CMakeLists.txt:559 (message):
NOT FOUND: 3RDPARTY_VTK_INCLUDE_DIR 3RDPARTY_VTK_LIBRARY_DIR
3RDPARTY_VTK_DLL_DIR
Do you have access to CmakeCache.txt in the build folder?
Can you detail the whole build environment?
(ana/mini)conda
Win version, native or VM
python 2.7 or 3.5
C++ compiler
Are you building locally or on a build server?
You are definitely drawing me in The whole build system looks like what PeterL94 was doing with CLBundler. The more I learn about this the more I like it!
-(ana/mini)conda
I am using miniconda3.5 but it is not important which conda version is used. You can always specify the python version (conda build . --python=3.5). But for windows only python3 makes sense so it’s simpler to use the python3.5 conda…
-channels:
with adding the conda-forge channels more packages are available:
conda config --add channels conda-forge
-win_vesion:
Windows 8.1 enterprise 64 bit. builds are made locally on a university pc. I would like to get the builds running first locally for all systems and then try to get all packages we need one by one into the conda-forge project… I don’t know if it is possible with the bigger ones (freecad, occt), but coin, pivy and others should work.
-compiler:
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
I can’t find any cmakecache file. (First time on windows after 4 years . locate doesn’t work)
Maybe the error occurs because tk isn’t found.
-- src/TKernel directory is not included
-- src/TKMath directory is not included
-- src/TKG2d directory is not included
-- src/TKG3d directory is not included...
I have now added tk as dependency of occt but still no success.
tcl is also a dependency and I don’t see a tcl package. Is it possible tcl is included in the tk package? They seem to always go together. They are separate in the libpack.
Also in cmakecache.txt line 187
CMAKE_LINKER:FILEPATH=C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/link.exe
tcl is also a dependency and I don’t see a tcl package. Is it possible tcl is included in the tk package? They seem to always go together. They are separate in the libpack.
I think there is no linker provided by conda. So cmake uses the default one. This is the same on linux. But I have no idea if the linker should have the same version.
The whole build system looks like what PeterL94 was doing with CLBundler. The more I learn about this the more I like it!