Roblox Studio crashing frequently in a place with Team Create enabled

Visual aids.
(The crash appears almost at the end of the video)

Direct links:

System information

  • Windows 11 (last update)
  • RAM: 8 GB GDDR5
  • CPU: Ryzen 5 7520U
  • GPU: Radeon 610M (CPU integrated)

Beta features: no one

The last lines of one of the crashes logs say this, though other logs end differently.

[DFLog::RakNetMissingPingPong] Time since last (ms): ping recv 40502, ping sent 5341, pong recv 45324, pong sent 40502, mtu ping recv 40497, mtu ping sent 5341, mtu pong recv 45320, mtu pong sent 40497, pkt recv 40497, pkt sent 3617, reliable recv 40497, ack recv 40656, oldest unacked send 40502, oldest unacked recv 301973 | MTU size: 1200 bytes
2025-02-15T20:48:59.071Z,302.071960,9920,6,Verbose [DFLog::RakNetMissingPingPong] Other stats: dead false, outgoingWaiting true, acksWaiting false, netCapacity 65536, resendBuf msg251, resendBuf bytes99065, loss last sec1, limitedByBw false, outputQueueSize 0

Expected behavior

The game is supposed to run without crashing when play testing it in Studio. But instead of doing that, it just lasts around 2 minutes before crashing Studio. Its a weird bug, since it only happens when playing the game in Studio and with a place with Team Create enabled. It does not happen in local copies, and it does not happen if playing the game published to the platform.

No error window appears either, Studio just crashes and thats it. It isnt a ram issue either, as it can be seen in the task manager the memory still has 2GB left before the crash.

A private message is associated with this bug report

Message to bump this, still happening frequently

Thanks for the repro file - can you also include a full log of one of the crashes so we can look at errors? Might help if we can’t reproduce on our end.

Sure, I just edited the private message associated with two logs, will provide more if requested.

I also discovered that it doesnt really need to have Team Create enabled, it happens if its uploaded to the cloud. Im not completely sure it works with local files completely, but based on my teammate experience trying it I would say that it does.

Great, thanks. Looks like there’s something funky going on with your usage of SharedTable that’s causing the crash. I’ve routed the issue to an appropriate team to follow up on.

Seems weird. In that reproduction file the only thing im doing is putting and updating a table that is later used in parallel for units targetting searching by a “swarm module”, didnt really know it could cause a crash like that

Hello. Thinking about your comment about shared tables I decided to investigate a bit further with script profiler. It turns out that the reason of the crashing was using SharedTable.Update frequently. Changing the code to work without using that function ever stopped the crashing entirely, and also improved the performance considerably.

Tho I managed to solve the problem, there should be some extra documentation as a warning of how slow and dangerous using that a lot of times is, and also some kind of indication to know if it crashed by that, since if we could have a way to know it by the logs or something a lot of time debugging and searching for information would be saved for a lot of other developers

Thanks, that’s good to hear. Did you remove the SharedTable usage entirely, or just reduce the update frequency? (If you’re still using it and have a “fixed” version it would be good to see exactly what you did). I’m not sure about intended usage and update rates, but for sure it should at least error out before crashing.

The shared table is used to store grid “cells” for units target searching (as it is a RTS game)

The game has a “tick” to do stuff with the units, that is 10 FPS (around 10 times per second)

So the SharedTable.update code was being used every 0.1s to update the cells of the shared table continously. I fixed the issue by just making the original cells table to be a shared one, allowing to not use that code again.