Segfault with ReconstructMesh

[fishcu]

Specifications like the version of the project, operating system, and hardware

Ubuntu 16.04, CUDA 10.0, OpenCV 4.0.0-rc built from source. 32GB of RAM, 12GB of VRAM.

OpenMVS is latest from master branch.

Steps to reproduce the problem

I'm trying to reconstruct a mesh. Same dataset as in #402. Dense reconstruction finished successfully. Here's the full output:

bin/ReconstructMesh -w /home/isaac/Downloads/buddha_recon_2 '/home/isaac/Downloads/buddha_recon_2/scene_dense.mvs' 
Eigen version 3.2.10 is used!
15:38:48 [App     ] Build date: Jan 21 2019, 15:07:48
15:38:48 [App     ] CPU: Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz
15:38:48 [App     ] RAM: 31.33GB Physical Memory 977.00MB Virtual Memory
15:38:48 [App     ] OS: Linux 4.15.0-43-generic (x86_64)
15:38:48 [App     ] SSE & AVX compatible CPU & OS detected
15:38:48 [App     ] Command line: -w /home/isaac/Downloads/buddha_recon_2 /home/isaac/Downloads/buddha_recon_2/scene_dense.mvs
15:38:48 [App     ] MapSMtoCores for SM 6.1 is undefined; default to use 128 cores/SM
15:38:48 [App     ] CUDA device 0 initialized: TITAN Xp (compute capability 6.1; memory 11.91GB)
15:38:58 [App     ] Scene loaded (10s398ms):
    41 images (41 calibrated) with a total of 235.27 MPixels (5.74 MPixels/image)
    11343837 points, 0 vertices, 0 faces
Points inserted 11343837 (100%, 1m5s432ms)           
Segmentation fault (core dumped)

(I added the eigen version line for debug purposes.)

I saw on #303 that you might need to use an exact Eigen version, so I use the one specified in build instructions.

Any ideas how to fix this? I should have plenty of RAM available.

For reference, here's an ldd output to show other libraries linked.

ldd bin/ReconstructMesh 
    linux-vdso.so.1 =>  (0x00007ffd95119000)
    libboost_iostreams.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x00007fb566ba6000)
    libboost_program_options.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.58.0 (0x00007fb566928000)
    libboost_serialization.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.58.0 (0x00007fb5666c7000)
    libopencv_calib3d.so.4.0 => /usr/local/lib/libopencv_calib3d.so.4.0 (0x00007fb5662e7000)
    libopencv_imgcodecs.so.4.0 => /usr/local/lib/libopencv_imgcodecs.so.4.0 (0x00007fb565957000)
    libopencv_imgproc.so.4.0 => /usr/local/lib/libopencv_imgproc.so.4.0 (0x00007fb564213000)
    libopencv_core.so.4.0 => /usr/local/lib/libopencv_core.so.4.0 (0x00007fb562653000)
    libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fb56242e000)
    libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fb5621d5000)
    libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fb561f61000)
    libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007fb560e61000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb560be1000)
    libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007fb5609dd000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb5607c0000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb56043e000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb560135000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fb55ff13000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb55fcfd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb55f933000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fb55f723000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb55f509000)
    libopencv_features2d.so.4.0 => /usr/local/lib/libopencv_features2d.so.4.0 (0x00007fb55f232000)
    libopencv_flann.so.4.0 => /usr/local/lib/libopencv_flann.so.4.0 (0x00007fb55efda000)
    libwebp.so.5 => /usr/lib/x86_64-linux-gnu/libwebp.so.5 (0x00007fb55ed7e000)
    libjasper.so.1 => /usr/lib/x86_64-linux-gnu/libjasper.so.1 (0x00007fb55eb29000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb55e925000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb55e71d000)
    libGL.so.1 => /usr/lib/nvidia-410/libGL.so.1 (0x00007fb55e3df000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fb55e1bd000)
    libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007fb55dfaf000)
    libnvidia-fatbinaryloader.so.410.79 => /usr/lib/nvidia-410/libnvidia-fatbinaryloader.so.410.79 (0x00007fb55dd62000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb566dbf000)
    libnvidia-tls.so.410.79 => /usr/lib/nvidia-410/tls/libnvidia-tls.so.410.79 (0x00007fb55db5e000)
    libnvidia-glcore.so.410.79 => /usr/lib/nvidia-410/libnvidia-glcore.so.410.79 (0x00007fb55bf83000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb55bc49000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb55ba37000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb55b815000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb55b611000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb55b40b000)

[fishcu]

Here's a backtrace from the release build. I'm currently running a debug build, but it's taking much longer (30m instead of 1m).

Thread 1 "ReconstructMesh" received signal SIGSEGV, Segmentation fault.
0x00000000005c3bd0 in SEACAVE::TFrustum<double, 4>::Set(Eigen::Matrix<double, 3, 4, 1, 3, 4> const&, double, double, double, double) ()
(gdb) bt
#0  0x00000000005c3bd0 in SEACAVE::TFrustum<double, 4>::Set(Eigen::Matrix<double, 3, 4, 1, 3, 4> const&, double, double, double, double) ()
#1  0x00000000005c434b in void DELAUNAY::fetchCellFacets<1>(CGAL::Delaunay_triangulation_3<CGAL::Epick, CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag>, CGAL::Location_policy<CGAL::Compact>, CGAL::Default> const&, std::vector<std::pair<CGAL::internal::CC_iterator<CGAL::Compact_container<CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag> > > >, CGAL::Default, CGAL::Default, CGAL::Default>, false>, int>, std::allocator<std::pair<CGAL::internal::CC_iterator<CGAL::Compact_container<CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag> > > >, CGAL::Default, CGAL::Default, CGAL::Default>, false>, int> > > const&, CGAL::internal::CC_iterator<CGAL::Compact_container<CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag> > > >, CGAL::Default, CGAL::Default, CGAL::Default>, false> const&, MVS::Image const&, std::vector<std::pair<CGAL::internal::CC_iterator<CGAL::Compact_container<CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag> > > >, CGAL::Default, CGAL::Default, CGAL::Default>, false>, int>, std::allocator<std::pair<CGAL::internal::CC_iterator<CGAL::Compact_container<CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Triangulation_vertex_base_with_info_3<DELAUNAY::vert_info_t, CGAL::Epick, CGAL::Triangulation_vertex_base_3<CGAL::Epick, CGAL::Triangulation_ds_vertex_base_3<void> > >, CGAL::Triangulation_cell_base_with_info_3<unsigned int, CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<void> > >, CGAL::Sequential_tag> > > >, CGAL::Default, CGAL::Default, CGAL::Default>, false>, int> > >&) ()
#2  0x00000000005df52c in MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float) ()
#3  0x000000000050ce00 in main ()

[fishcu]

Debug build backtrace. There's a failed assertion: Assertion `facets.empty() && inter.type == intersection_t::VERTEX && inter.v1 == vi' failed.

Full log:

Points inserted 11343837 (100%, 22m47s433ms)           
17:21:29 [App     ] Delaunay tetrahedralization completed: 11343837 points -> 4037991 vertices, 25318747 (+256) cells, 50637622 (+384) faces (23m56s7ms)
Points weighted 615 (0.02%, 504ms, ETA 0ms)...ReconstructMesh: /home/isaac/dev/openMVS/libs/MVS/SceneReconstruct.cpp:995: bool MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float): Assertion `facets.empty() && inter.type == intersection_t::VERTEX && inter.v1 == vi' failed.

Thread 11 "ReconstructMesh" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff9c384700 (LWP 29376)]
0x00007ffff0759428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff0759428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff075b02a in __GI_abort () at abort.c:89
#2  0x00007ffff0751bd7 in __assert_fail_base (fmt=<optimized out>, 
    assertion=assertion@entry=0xb9c258 "facets.empty() && inter.type == intersection_t::VERTEX && inter.v1 == vi", 
    file=file@entry=0xb98d80 "/home/isaac/dev/openMVS/libs/MVS/SceneReconstruct.cpp", line=line@entry=995, 
    function=function@entry=0xb9c340 <MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float)::__PRETTY_FUNCTION__> "bool MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float)") at assert.c:92
#3  0x00007ffff0751c82 in __GI___assert_fail (
    assertion=0xb9c258 "facets.empty() && inter.type == intersection_t::VERTEX && inter.v1 == vi", 
    file=0xb98d80 "/home/isaac/dev/openMVS/libs/MVS/SceneReconstruct.cpp", line=995, 
    function=0xb9c340 <MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float)::__PRETTY_FUNCTION__> "bool MVS::Scene::ReconstructMesh(float, bool, unsigned int, float, float, float, float, float, float, float, float)") at assert.c:101
#4  0x0000000000b07e69 in MVS::Scene::ReconstructMesh () at /home/isaac/dev/openMVS/libs/MVS/SceneReconstruct.cpp:995
#5  0x00007ffff0d1343e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#6  0x00007ffff15b86ba in start_thread (arg=0x7fff9c384700) at pthread_create.c:333
#7  0x00007ffff082b41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[fishcu]

If you want to reproduce, what data would you need? I can maybe try to make a smaller dataset, as scene_dense.mvs is +380MB in size.

[cdcseacave]

I need that file, u can share it on some drive.

[fishcu]

@cdcseacave OK, please try here: https://drive.google.com/open?id=1mUfRqMZha_lOVR5faAeF0jxaxdM0hdPx

I also tried to process the data on Win 10 instead, with the latest openMVS binary release, but it crashed with "wrong size for long", or something along these lines. I thought this was weird too. Both systems are 64 bit (x86_64).

[fishcu]

By the way, this is the error I get when running this exact dataset on Windows 10, latest release build (similar hardware):

D:\Photogrammetry\BuddhaHead\buddha_openmvs_test>D:\Photogrammetry\Software\OpenMVS_x64\ReconstructMesh.exe scene_dense.mvs
14:30:23 [App     ] Build date: Dec 21 2018, 18:08:41
14:30:23 [App     ] CPU: Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz
14:30:23 [App     ] RAM: 31.90GB Physical Memory 128.00TB Virtual Memory
14:30:23 [App     ] OS: Windows 8 x64
14:30:23 [App     ] SSE & AVX compatible CPU & OS detected
14:30:23 [App     ] Command line: scene_dense.mvs
14:30:23 [App     ] error: invalid stream (incompatible native format - size of long)

All of the data up to this point was created on Linux. I am now trying to re-create the data up to this point on Windows (with Win 10 builds of colmap and openMVS). I will also try to compile openMVS on Linux with the latest release build instead of latest master, to see if it makes a difference -- if yes, it would strongly point at some regression that can be tracked down and fixed. EDIT: Actually I just noticed that the latest master commit of openMVS is also the latest release commit, so that's not going to help us.

[cdcseacave]

I will have a look on your data The error you get on Windows is caused by BOOST library that is not able to produce a portable serialization between platforms no need to recreate all on windows, you can start from scene.mvs project, the one before densification, as that is stored in a custom serialization format I developed and that is portable

[cdcseacave]

All works just fine on a fresh Virtual Machine on which I installed Ubuntu 16.04 x64:

03:23:49 [App     ] Build date: Jan 23 2019, 03:05:42
03:23:49 [App     ] CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
03:23:49 [App     ] RAM: 31.41GB Physical Memory 0B Virtual Memory
03:23:49 [App     ] OS: Linux 4.15.0-24-generic (x86_64)
03:23:49 [App     ] SSE & AVX compatible CPU & OS detected
03:23:49 [App     ] Command line: scene_dense.mvs
03:24:58 [App     ] Scene loaded (1m9s15ms):
        41 images (41 calibrated) with a total of 235.27 MPixels (5.74 MPixels/image)
        11343837 points, 0 vertices, 0 faces
Points inserted 11343837 (100%, 3m2s147ms)
03:28:22 [App     ] Delaunay tetrahedralization completed: 11343837 points -> 4037991 vertices, 25318747 (+256) cells, 50637622 (+384) faces (3m18s497ms)
Points weighted 4037991 (100%, 2m21s143ms)
03:31:17 [App     ] Delaunay tetrahedras weighting completed: 25319003 cells, 50638006 faces (2m54s305ms)
03:33:30 [App     ] Delaunay tetrahedras graph-cut completed (8.50385e+06 flow): 2860813 vertices, 5721708 faces (2m12s956ms)
03:37:09 [App     ] Mesh reconstruction completed: 2860890 vertices, 5721428 faces (12m10s808ms)
03:38:26 [App     ] Cleaned mesh: 2859682 vertices, 5718350 faces (1m17s242ms)
03:39:29 [App     ] Cleaned mesh: 2859687 vertices, 5718391 faces (1m2s739ms)
03:39:56 [App     ] Cleaned mesh: 2859687 vertices, 5718391 faces (27s140ms)
03:40:24 [App     ] Scene saved (27s738ms):
        41 images (41 calibrated)
        0 points, 2859687 vertices, 5718391 faces
03:40:29 [App     ] Mesh saved: 2859687 vertices, 5718391 faces (4s991ms)
03:40:29 [App     ] MEMORYINFO: {
03:40:29 [App     ]     VmPeak:  9199700 kB
03:40:29 [App     ]     VmSize:  1718416 kB
03:40:29 [App     ] } ENDINFO

[fishcu]

Thanks for testing! The only things on my machine which are not perfectly according to your setup guide are OpenCV (newer version 4.0.0-rc instead of 3.x version from libopencv-dev), and Ceres (latest release instead of latest commit).

Does ReconstructMesh use OpenCV at all besides image loading? Could that explain the crash? I can try Ceres with latest commit instead of latest release, but I doubt it will make a difference.

Any other ways I could debug this?

FYI, I've attached the output of cmake. Eigen information is missing as I have a conflicting version and hacked it to load from the specific eigen 3.2 path instead.

CMake Deprecation Warning at CMakeLists.txt:30 (cmake_policy):
  The OLD behavior for policy CMP0011 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.

-- cotire 1.8.0 loaded.
-- Detected version of GNU GCC: 54 (504)
-- WARNING: BREAKPAD was not found: Please specify BREAKPAD directory using BREAKPAD_ROOT env. variable
-- Can't find BreakPad. Continuing without it.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   iostreams
--   program_options
--   system
--   serialization
--   regex
-- OpenCV 4.0.0 found (include: /usr/local/include/opencv4)
-- CGAL 4.7 found (include: /usr/include)
CMake Warning (dev) at libs/MVS/CMakeLists.txt:9 (FIND_PACKAGE):
  Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
  Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  CMake variable VCG_ROOT is set to:

    /home/isaac/dev/vcglib

  For compatibility, CMake is ignoring the variable.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- VCG  found (include: /home/isaac/dev/vcglib)
-- GLEW  found (include: /usr/include)
-- GLFW3 3.1.2 found (include: /usr/include/libdrm)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/isaac/dev/openMVS/openMVS_build

[cdcseacave]

hacking eigen is your problem, unhack it

[fishcu]

Eigen is a header only library, and I just forced it to use the correct version. I'm pretty sure Eigen is not the problem. The official guide of installing an older Eigen version over the system one seems counterproductive to me. I'd rather keep a separate installation.

Any other ideas what might cause the crash?

[cdcseacave]

Eigen is header only, but used in multiple libs, and if linked statically can be a problem, for example CERES. OpenCV and Boost version make no difference, and I use same CDAL version. So no other ideas, sry. Try in debug or relwithdebinfo and run a GDB

[chris-aeviator]

same here:

❯ /var/lib/snapd/snap/openmvs/2/command-ReconstructMesh.wrapper project_dense.mvs 
21:57:36 [App     ] Build date: Mar  9 2019, 15:07:14
21:57:36 [App     ] CPU: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
21:57:36 [App     ] RAM: 15.38GB Physical Memory 15.37GB Virtual Memory
21:57:36 [App     ] OS: Linux 4.20.10-arch1-1-ARCH (x86_64)
21:57:36 [App     ] SSE & AVX compatible CPU & OS detected
21:57:36 [App     ] Command line: project_dense.mvs
21:57:36 [App     ] MapSMtoCores for SM 6.1 is undefined; default to use 128 cores/SM
21:57:37 [App     ] CUDA device 0 initialized: GeForce GTX 1070 (compute capability 6.1; memory 7.93GB)
21:57:45 [App     ] Scene loaded (8s793ms):
    99 images (99 calibrated) with a total of 379.82 MPixels (3.84 MPixels/image)
    14377566 points, 0 vertices, 0 faces
Points inserted 14377566 (100%, 1m14s503ms)           
21:59:09 [App     ] Delaunay tetrahedralization completed: 14377566 points -> 8350273 vertices, 53968917 (+340) cells, 107938004 (+510) faces (1m20s133ms)
Points weighted 17741 (0.21%, 100ms, ETA 0ms)...[1]    10039 segmentation fault (core dumped)  /var/lib/snapd/snap/openmvs/2/command-ReconstructMesh.wrapper 

getting the same result when using the AUR version (using snap here)

[chris-aeviator]

I tried the same step in a docker container, and it will error out with bad_alloc in the same step, consuming 15.x / 16 GB of RAM.

Is there any way around the Memory restrictions?

[cdcseacave]

Right, you need more RAM to reconstruct that scene. Try using -d with a higher value, or split the scene in smaller subscenes and reconstruct them individually.

[vwarriar]

Same issue I have created a new open issue as this has been closed.