Hello metalfox, seeing your crash log and the other post in the off topic section, it looks like you're using too many vertices (and I assume, direct deformations) and your computer can't take it.
I'd suggest you take a look at your metrics, especially:
Meshes - Spine User Guide: Vertex count
Metrics - Spine User Guide: Vertex transforms

Here's another thread discussing why it is important to keep these numbers down:
Editor frame rate performance issues

Hey metalfox, sorry for the trouble. Could you please send us your project, so we can further investigate why Spine is running out of memory? Please send it to contact@esotericsoftware.com with a link to this forum thread.

Hello metalfox, I was not blaming your specs, but usually when people get the java.lang.OutOfMemoryError: Java heap space the culprit often is a wild usage of vertices, or bones per vertex. It might not be your case of course, but it doesn't hurt to check this first.

From the link I posted above Nate said:

Yeah, I'm a bit scared people go crazy with mesh deforms. Every deform key has to start all mesh verts. Also, each vertex (a float) is stored for every bone that affects a vertex. So a mesh with 100 verts where each vert is affected by 3 bones is 300 verts, then someone goes and keys that mesh a dozen times in 20 animations = 12 * 20 * 300 = 72,000 verts stored! This affects data file size and memory consumption, but at least CPU isn't affected.

It doesn't look like you're using mesh deforms which is great, so this one is out.

Then again Nate said:

Probably you don't have vertices which are influenced by ALL those bones. It's per vertex. If a vertex is influenced by 4 bones, then 4 floats are stored for that vertex in the setup pose, current pose, and every key. Also, for every bone that influences a vertex, a vertex transform is calculated. You can see the number of vertex transforms in the Metrics view. Using Purge in the Weights view can remove the bone influence that is very small, which can make a big difference. See the docs for details:
Meshes - Spine User Guide: Vertex count
Metrics - Spine User Guide: Vertex transforms

(same docs I posted above earlier just in case)

So maybe the problem could be that you have over 3-4 bones per vertex, and this is generating a lot of calculations for Spine.
To help with this, you could use the Prune function: Weights - Spine User Guide: Prune which recently got updated so that you can choose the maximum number of bones affecting a vertex.

If this doesn't help, as Badlogic said, it would be great to see the project, you can send us the project with the textures all black.
Spine shouldn't crash even in these cases, so having a repro file would really help us out. If you still can't, don't want, we can just hope it was one of the problems above, or hope it doesn't occur again, but we won't be able to guarantee your problem is fixed of course.

Regarding backups, Spine automatically saves them in the backup folder: Settings - Spine User Guide: General
You should be able to find this folder by going to the Files section, then clicking on the folder icon of the Backup row:

I hope this will help!

The vertext layout in a shader is fixed. What you described amounts to run length encoding, something you can't do with vertex data. But we aren't talking about GPU sice issues here. What you are running into is a CPU side issue.

Your data above gives us some idea about your project setup, but ultimately, we'll need a project that reliably crashes for you to identify the underlying issue. We'd be grateful if you could either send us a blacked out version of your real project, or a new, non-secret project that simulates the traits of your real project.

I'm in fact one of the programmers on Spine. I believe I have a pretty good handle on how our code works, and how GPU and CPU side skinning and data representations work. I understand that text communication can be frustrating if there are misunderstandings, but please keep it civil.

I understand entirely what you are trying to say, even though phrases like "hexadecimal code", "uniforms out the information", or "form a grid of information" aren't quite what a programmer would use for what you are describing.

What you are referring to as "hexadecimal code" is a packing of bone indices, say a byte per index, with a maximum of 4 indices encodable in 32-bit. For good measure, you can also throw in lower precision weights and even UVs, say fp16, to pack more data into the same amount of space, though that may actually lead to quite a noticeable degradation in the precision of the skinning and texture sampling itself. All of that has nothing to do with "hexadecimal code" though...

The phrase "uniforms out the information" is also nothing a programmer would say. I assume you are talking about matrix palettes stored in uniform buffers, which is an encoding used by most GPU side skinning shaders to share bone transforms across vertices. The bone indices in the vertex point into that palette.

"add an additional float then" is not possible GPU side. These floats are stored as part of a vertex. The vertex layout is fixed. You can not do run-length encoding in a vertex layout, unless you make every vertex as big as the worst run-length encoding requires. In which case you actually waste more memory than needed.

All of the above comes with tradeoffs that you might be able to live with at runtime in your game/app:

• Number of bones that can influence a single vertex, limited to 4 in a 32-bit packed encoding.
• Number of total bones limited by uniform space, but more importantly, the 32-bit packing, with one index being represented by a byte, limiting the total number of bones in a single pass to 256.
• Precision of weights may result in huge deviations in skinning outcome compared to the high precision mode you see in the editor.
• Precision of UVs may result in texture sampling artifacts compared to the high precision mode you see in the editor.

Again, you can do all of that at runtime, in your game, if you can live with the restrictions and plan your assets accordingly.

But for the Spine Editor, we can not make do with these restrictions. The core data structures in the editor must allow for maximum precision, bone numbers, and other factors that do not turn up in a runtime setting. There are also a bunch of algorithms applied to meshes that have a minimum space complexity of O(n²) (yes, there are no lower complexity solutions for some of these). Whether things are stored/computed GPU or CPU side is entirely irrelevant for the issue at hand.

We won't be able to fix your issue without a reproduction case. We currently lack such a repro. You said you won't send us anything. Please ask your programmers how they feel about fixing an issue without being able to reproduce it.