ID:1613720
 
BYOND Version:506
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 30.0
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

I run the biggest SS13 codebase (most bloated? Most features? Anyways, it's got the most stuff in it right now), and I've hit a wall. I can't create new objects/variables? Hitting some sort of BYOND hard limit.

Numbered Steps to Reproduce Problem:

https://github.com/ZomgPonies/Paradise

compile this. This works, it's JUST on the verge of the limit.

Cherry-pick this into it, standard code nothing fancy in it. It also broke with a different commit earlier in the day that I rolled back.

https://github.com/ZomgPonies/Paradise/commit/ d33614b778c97c3031b1b39835cf5ae5fa25c53c

Compiles fine, but as soon as you run the game you run into lots of random things breaking down, and some BYOND specific runtime codes:

http://pastebin.com/raw.php?i=BLTcet5C

Other runtimes I'd never seen before:

runtime error: writing to read-only variable
runtime error: reading from non-readable variable


Expected Results:

Compiling normally, running normally since the hard limits on strings and other stuff had been increased in the 32-bit work that was done recently.

Actual Results:

Completely breaks down the codebase, forcing me to stop all devwork until this is resolved.

Does the problem occur:
Every time? Or how often?

Every time I try adding new objects to the codebase.

When does the problem NOT occur?

Not adding new code I guess?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Never hit the limit anywhere else. Running the latest BYOND. Problem happens on my host server, running same BYOND version.

Workarounds:

Non currently, short of stopping all coding.
Errr yes quite sure. Did you even LOOK at the logs I posted?
Urm did you read your own logs...
It's possible that at some point you've added code to your source that eats up all your memory. I accidentally did this myself once.

It's hard to know if this is a programming problem or a BYOND limit seeing as virtually none of the code was written by you and you've probably added so much willy nilly that looking back at what you've added isn't really much of an option.

I'd suggest going through all the most recent things you've added, taking them out and seeing if the problem continues. If it doesn't then you know that what you took out is the cause of the problem.

Otherwise, revert the game to a version that WAS functioning. Then work from there again. A pain? Yes. Your last option? Probably.
Looks like somewhere in there you are reaching >65K unique instructions in a single function.
So much for having the "biggest" SS13 codebase.
But seeing as you're open-source, you may find it difficult to track exactly where it came from. So Zecronious's last option is probably best.
Ran some more tests, and found out that it's a limit on the amount of procs. Either brand new procs or redefined children.

/world/proc/Test()
return

/obj/structure/snowman/attackby()
return

Both of these break the codebase however

/obj/structure/snowman/blue

Works fine, so it's not an actual path limit.
In response to Ter13
Ter13 wrote:
Looks like somewhere in there you are reaching >65K unique instructions in a single function.

Now the question is, is there a single global function that regroups all other functions beneath it? I just made a list of all unique procs for my codebase, 9274 (excluding global procs/instructions). If I added in all of the redefined children, chances are it would be around 65k.

http://www.byond.com/forum/?post=1284595#comment5231905

The 65k limit for procs was allegedly removed in BYOND 500, but if all procs other than globals fall under a single function, that sort of defeats the purpose, no?
65K instructions in a single function. Jesus, what biblical monstrosity have you created?
Welcome to SS13. I'm barely a few months worth of commits ahead of the rest of the major codebases, so this is something that's going to affec the SS13 community at large sooner rather than later.
SS13 is being remade anyway off BYOND. http://spacestation13.com/

So to get this right. If you were to take away 2 procs, that would give you the ability to add two more procs?

Are you getting a 1 to 1 ratio? That would prove for certain that it's the number of procs you have defined.
That remake is for all intents and purposes in limbo. BYOND SS13 development is still very much active, hence why spacestation13.com is putting work on their website to become a portal for ALL things SS13.

And yes, I am getting a 1:1 ratio.
In response to ZomgPonies
Fair enough. Well you're right. Other sources will hit this problem if they haven't already.

I have a feeling, just a hunch that there's a bunch of procs you can get rid of or combine some to minimize.

Is that a temporary solution to keep your sever going?
Lord knows there's tons of deprecated code. I'm trying to clean it out as best I can as a stop-gap solution so I can keep adding bugfixes (while having stopped all feature production). However I would love to get some feedback on this from Lummox or Tom to acknowledge the problem exists and
to find a more permanent solution to the issue.
Absolutely, *shouts* "TOMMMMMM" :)
What I think will help is if I can get a copy of the source with the high number of procs, so I can see the problem trigger in DM. The proc IDs were indeed upped past 64K, but that kind of situation was basically impossible to test properly without a codebase hitting that limit, which none did at the time (because path limits hit first).

You can email me at [email protected] or send a pager message. Usually these codebases are enormous so you'll probably want to put it up somewhere and just send me the download link.

Incidentally the limit of 64K instruction codes per proc is still in effect.
Incidentally the limit of 64K instruction codes per proc is still in effect.

I still feel like 64K instructions is much more likely than 64K procs being defined and on top of that, the fix for >64K procs not working.
IIRC the compiler should be spitting out specific errors when it hits the instructions-per-proc limit, though.

That said, "bad instruction" at runtime does read exactly like a single proc gone wild.

I just realized I could get the source to test this from the github repository posted above, but as is the case with such things I'm not certain if that's changed since the initial report.
Heh I cleaned out unused code too well, give me a few hours to hit the wall again ;)
Alright Lummox here are the instructions to reproduce:

Download https://github.com/ZomgPonies/Paradise/archive/rollback.zip

Copy config/example/admins.txt and admin_ranks.txt up one level to config.

Edit admins.txt and add your ckey - Host as in:

Zomgponies - Host

Compile, run. You'll get a single runtime because the savefiles have been converted to MySQL, it can be ignored.

Wait for server to load in, then you can go to Server tab -> Start now.

Join in as any job, you'll see no runtimes.

TO BREAK:

Add ANY proc for example

/world/proc/Test()
return

/obj/structure/snowman/attackby()
return

Compile, run the same test. The moment your character spawns in, you'll see weird runtimes related to the AI eye mob/object. If you press F6 which usually pulls up a javascript player panel, you'll get a bunch of other runtimes. Runtimes will look like

http://pastebin.com/raw.php?i=BLTcet5C

Let me know if there's anything else you need in these instructions.

Page: 1 2 3