ID:1693911
 
BYOND Version:507
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 37.0.2062.124
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Daemon/Seeker (depending on what you are hosting on) crashes when saving a long list when other lists are inside of that list. Debugging with Visual Studio 2013 reveals the crash to be caused by stack overflow.

Numbered Steps to Reproduce Problem:
1. Download the Misuterii High Map Editor here: https://dl.dropboxusercontent.com/u/176781620/ Misuterii%20Map%20Maker.zip

2. Run the Map Editor.

3. Change Map to Custom, selecting the .mhm and then .obj file in this archive: http://www.mediafire.com/?7ra05ljb5sob9r4 (Courtesy of He_Without_Sorrow [Egil])

4. Join and start the game.

5. Right click one of the desks and press Copy Object.

6. Left click and move the mouse to make a bunch of desks.

7. Go to the Map Maker Commands tab and save the map as anything.


Code Snippet (if applicable) to Reproduce Problem:
//list set up as follows: list(list(type,x,y,z,step_x,step_y,list(list(varname,varvalue))),etc.)


Expected Results:
The map saves as per usual.

Actual Results:
Dream Daemon/Seeker crashes, possibly due to stack overflow.

Does the problem occur:
Every time? Or how often?
Every single time.
In other games?
Not tested.
In other user accounts?
Yes.
On other computers?
Yes.

When does the problem NOT occur?
When the object count (in the list) is lower or equal to 309.

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.)
Not tested.
EDIT: Now tested, older versions do not work.

Workarounds:
Create multiple lists and/or multiple save files.

Perhaps it is the saving of duplicate icon files? I might have to change how duplicates are handled. Either way, still wanted this to come to attention.
Does the list ultimately contain itself? I could see that potentially being an issue.

Obviously this is something I want to fix regardless, but a good workaround would be avoiding situations that could lead to potential problems.
The list does not contain itself at all. If that were the case, it'd probably be overflowing before getting to 309 objects.