[3dprinter-general] Bug#1056897: Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=?=(<brace-enclosed initializer list>)=?UTF-8?Q?=?UTF-8?Q?’ is ambiguous

[Gregor Riepl]

> Gah, looks like some arch-dependent glitch. Which explains why it didn't 
> happen to either of us (we probably both used amd64 machines, I 
> definitely did) and then the failure did happen upon publishing.
> 
> Thanks for your help, I'll try to help get the next fix in once it's ready.

Ok, so I have a preliminary status report.

I debugged the issue on i386 first, because that's the easiest to do 
with standard PC hardware.
In contrast with the other architectures, the value reported by the 
failed unit test is off by several orders of magnitude on i386, while it 
seems to be "only" a sign issue on other architectures.

I've isolated the issue to make debugging easier, and that revealed 
incomplete initialization of the Slic3r::arr2::GravityKernel object - 
this object is allocated on the stack by the unit test, and while the 
constructors of all fields are called, the field active_sink remains 
uninitialized.

This is apparently by design, as stated in the Eigen documentation (the 
LA library used by Slicer):
https://eigen.tuxfamily.org/dox/group__TutorialMatrixClass.html

 > A default constructor is always available, never performs any dynamic 
memory allocation, and **never initializes the matrix coefficients**.

So, this is most definitely a bug in PrusaSlicer, because it doesn't 
explicitly assign an initial value to 
Slic3r::arr2::GravityKernel.active_sink - but uses it later anyway.

I don't know why this only causes issues on i386, but it's certainly 
dangerous on all architectures.

The fix quite easy, though.
Modify line 20 and 21 in 
src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp as follows:

-    GravityKernel(Vec2crd gravity_center) : sink{gravity_center} {}
-    GravityKernel() = default;
+    GravityKernel(Vec2crd gravity_center) : sink{gravity_center}, 
active_sink{0, 0} {}
+    GravityKernel() : active_sink{0, 0} {};

I'll file separate bug report + corresponding upstream report later.

Now, I don't know if this will fix the issues on the other 
architectures, but I'll try to reproduce them on an arm64 device at 
least. It's very likely that the issue is the same everywhere.