Game crashes within a few minutes with memory access violation

Playing the game mentioned in the direct links on PC (specifically Windows) causes crashes within minutes. This is consistent with other Windows PC and android users in our community. For iPhone, iPad, Xbox, and Mac users, they seem to not be affected.

Visual Aids; see gif;
crashonroblox

Direct Links: squish_animation_testing - Roblox

System information:
-CPU: AMD Ryzen 7 5800x 8-core @3.8 GHz
-Ram: 32 GB
-GPU: NVIDIA GeForce RTX 3060 Ti

Reproduction files:
See direct link to the place showcasing the issue. It takes a minute or two to crash. I can post the .rbxl if needed.

06/23/23 Update:
We disabled Squishmallow AI movement behavior and that reduced the number of crashes significantly, but it still happens with less frequency.

We think it may be tied to either the rigs/animations, OR the fact we use RigidConstraints on the rig’s bones to attach the face rig to the Squishmallow.

Expected behavior

The game plays as normal with no crashes.

A private message is associated with this bug report

9 Likes

Update;
After trial and error of enabling and disabling many, many features; it boiled down to the animations played on the custom rig for the Squishmallows.

We still don’t know the cause, other than simply allowing animations to be played causes crashes only on Windows. Again, a weird emphasis on the fact it didn’t cause issues on phone, tablet, xbox, or mac.

5 Likes

Another update;
I managed to isolate the issue into a solo place;

I also managed to find this error: “exception while signaling: invalid hash bucket count”

image

4 Likes

Final update;

The issue was caused by putting a particle emitter inside an animated bone. When the bone is not being animated while a particle emitter is inside it, it does not crash.

3 Likes

There is a big issue with bones, Bones are essentially just attachments, they are a derived class from attachments and may have some unexpected behavior with Lights, Particles or any Instance that expects a Instance called PVInstance.
My recommendation for now is, you can use “RigidConstraints” and attach a attachment to the bone, then put your ParticleEmitter inside of the attachment instead of the bones.
RigidConstraints will update with animations.

Because the particle’s emission location isn’t vital, I just set the parent to the body that holds the rig, and it seems to hold up fine.

In the place linked in Direct Links, there is a button that once pressed will switch the destination of the new particles parenting to the bone. It usually crashes within seconds.

Yes, thats exactly why it crashes. Bones and Attachments are very buggy with instances that require a PVInstance. You can try reproducing this in studio by parenting a light like this.

RootPart.Bone.Bone.Light = Output will error as it expects a PVInstance. Attachments/Bones do not have this unless the bone is a child of a Part.

RootPart.Bone.Light = works. Parent of the bone is a part which it can pull a PVInstance from.

Im not sure about particles, but i am very sure they also require a PVInstance like Lights and so on.

I’m aware; the full skeletal rig I use in the demo is parented to a pvinstance.

The reason for this devforum post is documentation;
before Thursday June 22nd there were no issues with putting a particle emitter inside an animated bone (and the rig was within a pvinstance), and then suddenly a roblox update started causing the crashes.

Its just ancient garbage code that was never updated. Roblox engine developers decided to instead of making bones a new class in the engine, to add a slightly modified derived class of attachments. Thats why we also got no scaling for bones as attachments dont have a scale properly. Unfortunate but what can you do about it? Their team, their choice I guess.

Hello,

I just received this and I will be looking into this. Thank you so much for adding a repro case, that will make finding and fixing the issue a lot better.

I will post once I have more info.

Fantastic, glad to hear it; the place I have linked for repro is still active, so its a great way to consistently check it out.

Hello again,

So that was quite painful to figure out. I’ll spare you the gritty details, but from a high level it was a knock on bug from another fix that was done where particle emitters wouldn’t follow bones and a fix was made that wasn’t multi thread safe.

Again thank you so much for sending the test place! I can imagine you spending a lot of time trying to minimize the problem and pinning it down and then recreating this test case. And I cannot stress enough how valuable it was to have this specific repro case. I’ve done so many runs in it I can’t even count. And I cannot imagine how hard it would have been to track down without this test place. I was wondering though if you could send us a private copy of the RBLX of the test place? That way we can see how it was built and build a similar test, that doesn’t use your specific assets, to integrate it into automated testing.

1 Like

Sure thing, I’ll link the .RBXL file in the private message.

1 Like

Fix should be in shortly, this will be part of the new release in 1.5 weeks or so.

Thanks again @TigerCaptain for the repro case, I wish more people filed bug reports like that.

3 Likes

We’ve released a fix for this a few hours ago. Please let me know if it doesn’t work. Thank you!

1 Like

I hopped into the test place and it seemed to show promising signs; I’ll publish an update to the main game tomorrow and see how it goes there.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.