Hello Spine team!
We use the spine-cpp 4.2 runtime in a custom engine, and have recently encountered a crash with a spine that uses a ClippingAttachment.
The problem happens on this line:
EsotericSoftware/spine-runtimesblob/59bcffcf42654465903638811e18c51c87a5c240/spine-cpp/spine-cpp/src/spine/SkeletonClipping.cpp#L127
The new Vector size computed by clippedTriangles.setSize(s + 3 * (clipOutputCount - 2), 0); is negative. Since setSize expects a size_t, which is unsigned, this results in a realloc of 4 GBs or more and it breaks.
The culprit may be the SkeletonClipping::clip() method called before that, that only returns 1 vertex / 2 floats.
I linked a zip with an edited spine-sdl sample that generates this crash. (it contains the .spine + its export + relevant code to setup the tracks)
Runtime information
Spine-cpp runtime 4.2 at this commit: EsotericSoftware/spine-runtimese9cd51e
Some notes
- Happens at least on iOS, Android and Mac M1+.
- The spine only crashes with very specific track timings, skeleton position and even the texture export scale matters.
Bone::setYDown() also matters, I disabled it in the sample.- We don't see any issue when replacing the code in SkeletonClipping.cpp by the version before this commit EsotericSoftware/spine-runtimes
f997a5f
- The buggy realloc does not happen with C runtime. The
_setSize() function expects an int there so the array will already have more than a negative capacity. The following computations may still be wrong though.
- There is an assert
assert(newSize >= 0); in Vector::setSize(). This will never detects anything because newSize is unsigned.
Thanks for the help!
