"double free or corruption (!prev)" in quadric_simplify_mesh

[gllmflndn]

With the exemplar attached mesh (20480 faces), quadric_simplify_mesh runs successfully at reducing the number of faces from 20479 to 3750 but crashes when requesting 3749 faces (aggressiveness set to 7.0):

 iteration 0 - triangles 20480 threshold 2.187e-06
 iteration 1 - triangles 11952 threshold 1.6384e-05
 iteration 2 - triangles 7700 threshold 7.8125e-05
 iteration 3 - triangles 4790 threshold 0.000279936
 iteration 4 - triangles 3748 threshold 2.22045e-16
double free or corruption (!prev)

sphere.zip

[neurolabusc]

I am unable to replicate this issue. This project takes a NIfTI volume as input, not an obj file. Can you create a github repository with your source project to demonstrate some issues, and also provide details regarding the computer and compiler used (e.g. MacOS with gcc).

This code is a pure C implementation of this C++ code that creates a minimal tool for simplifying obj meshes. It does not exhibit the behavior you describe (on a Windows computer with the cl compiler).

[gllmflndn]

I am currently using the C++ implementation here but would happily swap it for a C implementation so I wrote another MEX wrapper around quadric_simplify_mesh and that's where I observe the problem (Linux with gcc 9.4). I could share this wrapper but would you prefer a C only function that reproduces the error instead?

[neurolabusc]

@gllmflndn I have been able to replicate and fix your issue. To replicate and de-bug the issue I added the -t threshold parameter to the obj2mesh program and compiled it in sanitized mode to identify any memory issues:

gcc  -O1 -g -fsanitize=address -fno-omit-frame-pointer   -DNII2MESH -DHAVE_ZLIB MarchingCubes.c obj2mesh.c isolevel.c meshify.c quadric.c base64.c bwlabel.c radixsort.c -o obj2mesh -lz -lm
./obj2mesh -t 3749 -v 2 sphere.obj smoother.obj

This revealed that the refs array was too small to grow. In my C code, I pre-allocate this array with a worst case scenario size as there is a big performance penalty for growing its size. Clearly, my calculation for worst case scenario was not conservative enough, so I increased the buffer and the code now works without any memory exceptions and to a nice completion.

[gllmflndn]

Thanks @neurolabusc I confirm that with your fix I could reduce my example mesh for any value between 20480 and 1 and it ran smoothly.

On a very minor note, I notice a warning when compiling with -Wall:

quadric.c:452:7: warning: ‘iterationStartCount’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  452 |    if (iterationStartCount == (triangle_count-deleted_triangles)) break;
      |       ^

It's not a very pertinent warning here but I silence it with int iterationStartCount = 0;

[neurolabusc]

Thanks! I am closing this issue. The sphere is an interesting edge case in that initially all vertices have identical collapse costs.