String.pack's `c[n]` format option can create very, very large strings and hang the process

Bug Reports Engine Bugs
#1

While writing some code earlier, I accidentally caused string.pack to try to write a 18446744073709551615 character string. It instantly froze Studio and started slowly using more RAM, leading me to believe it’s actually attempting to create a 18446.7 petabyte string. Given that other functions that allocate memory (string.rep, table.create, etc.) all have limits on the amount they can allocate, this seems like an oversight and should be fixed.

To reproduce this:

  • Run this code: string.pack("c18446744073709551615", "")

It doesn’t matter where you run it. I ran it in Studio and in-game and it caused both of them to hang.

I’m running Windows 8.1 and have 8 gigabytes of ram, in case it’s important. This is happening in release 450.

I have not generated dump files because this doesn’t seem like a particularly esoteric issue, but if need be I will do so.

2 Likes
#2

I don’t see what’s suprising about this.

while true do end will also instantly freeze Studio, among any number of other things which attempt unbounded amounts of memory allocation or computation. It would be nice if Studio did not hard-freeze under those kind of circumstances, but that has nothing to do with any particular function.

Almost any sufficiently powerful API will expose many ways to do arbitrarily large amounts of work, trying to prevent that is a losing battle for a couple of reasons:

  • Sufficiently creative users will always find new ways to do too large an amount of work, provably so because actually preventing that would amount to solving the halting problem.

  • Where do you draw the line on what’s “too much” work? 18446744073709551615 is certainly too many characters, but what about 2147483647?

5 Likes
#3

So is there any recommended amount of characters you should be using/ what is the limit that doesn’t crash?

1 Like
#4

Like everything else that depends on the platform, but it’s not something you need to worry about at all in practice: The primary use case for string.pack is data stores, and you will hit the data store size limits far before you hit the limit of how big a string you can generate with string.pack.

2 Likes
#5

Thanks for the report! This is indeed a bug and will be fixed.

3 Likes
#6

I was hesitant to make a bug report for that exact reason, actually. Generally I try not to make reports for issues that are clearly user error.

The only reasons I made a report for this particular one are that:

  1. I encountered it on accident and it was annoying to debug
  2. The other functions that do similarly arbitrary allocstions have a hard limit

Generally I would argue that built-in API should be hard to misuse, and I accidentally shot myself in the foot with string.pack over a simple math error (that’s how I ended up with such a large number; I formatted -1 using %u). It should ideally not hang the process if you make a basic mistake.

Either way though, Zeuxcg has said this will be fixed so it’s a moot point.

2 Likes