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.
