ID:2044362
 
BYOND Version:509
Operating System:Linux and windows 7 pro 64bit
Web Browser:Chrome 48.0.2564.116
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Alright, so based on what i said in http://www.byond.com/ forum/?post=2038874&page=2#comment18832582 we at /tg/ made a tool to convert maps to a more expanded map format for the sake of better git merge support and i think we blew up DM.

We would like to at least understand what bug/limit we hit up against (so we can program against it), if not see about getting it removed/reworked.


How the expanded map format works, is we define things a bit differently.

Here is a sample format, this one (and almost all of our maps) compile and work in DM, Dream Maker, and Dream Deamon: https://github.com/AndrewJacksonThe2nd/-tg-station/blob/ c0cba8e62dc3430832872489cac4aa2402d2fe64/_maps/RandomRuins/ SpaceRuins/asteroid2.dmm (time frozen link)

Heres the issue:

One of our maps causes a crash during the saving dmb step of compiling under both linux and windows.

Linux error: *** glibc detected *** DreamMaker: realloc(): invalid old size: 0x0e85ed38 ***

Windows error:
Faulting application name: dm.exe, version: 5.0.509.1319, time stamp: 0x56901af5
Faulting module name: byondcore.dll, version: 5.0.509.1319, time stamp: 0x56901af4
Exception code: 0xc0000005
Fault offset: 0x0009aa20
Faulting process id: 0x2b74
Faulting application start time: 0x01d1711c8e300c8d
Faulting application path: C:\Program Files (x86)\BYOND\bin\dm.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: e88a3a86-dd0f-11e5-ba21-b39ec1435c92

Reproduce:

Download: https://github.com/AndrewJacksonThe2nd/-tg-station/archive/ c0cba8e62dc3430832872489cac4aa2402d2fe64.zip (time frozen link)

open up in DM

expand the _maps folder

uncheck tgstation2.dm and check astroidstation.dm

compile.

astroid is our biggest map it would seem, so that might be related.
The map that is causing this crash is asteroid/z5.dmm, not the station map itself. So far only that one map causes the crash, all other maps compile just fine when written in the expanded format.
bump.

lummox, could we at least get a hint as to whats up in 0x0009aa20 (509.1319)
Sorry, haven't gotten to this yet. Tracing these things takes time and I've been focusing on the big icon thing.
My previous post is wrong, it can crash at any point when compiling 'asteroidstation.dm' (includes all the asteroid station maps), at any point, can either be when loading 'asteroidstation.dmm' itself or any of the z level dmm files.

It can also load all of those without crashing and crash at the last step (saving the dmb file).

By mixing which maps I include (replacing either 'asteroidstation.dmm' or 'asteroidstation\z5.dmm') I can get it to compile successfuly, but not always.


edit:
A link to download a project set to compile Asteroid Station and with all station maps and z levels converted to the new format.
https://github.com/xxalpha/-tg-station/archive/ testasteroidcrash.zip
bump
bump
Bump. Merge-friendly giant maps must live, and as a byond member for a long time I'd really love to see this focused on as it's near and dear to development that I'm working on.
I've added this to my ongoing list so I can take a look.
Good gads. The compilation process here takes forever, and I'm afraid of even trying it in the debugger. I'm not sure if I'm going to be able to make any headway on this at all.

I will say that the example map has no problems at all compiling in a blank project with the type paths added. This suggests that there's a memory component brought on by tgstation's mondo ginormousness.
I am glad you got to investigate this, thanks for the hard work.

Are you still working or planning on trying to fix this?
oh, ya, i forgot about this.

I will say that the example map has no problems at all compiling in a blank project with the type paths added.

The example map does compile. it's only our biggest map, asteroid station, that didn't compile.

We ended up just scrapping the map because it wasn't really liked anyways, but we do live in fear of running into this issue again with bigger maps.
The example I gave has the Asteroid map to be compiled by default, I think Lummox used that one.
In response to Xxnoob
Xxnoob wrote:
I am glad you got to investigate this, thanks for the hard work.

Are you still working or planning on trying to fix this?

I would if I had a case that caused the crash without consuming mondo ginormous amounts of memory or taking almost literally forever to compile. I can't investigate something like this when the compilation times are so extremely long.
Well, it does only break in these cases.