Compiling this (updated current tgstation code, compiles fine on 511) :
https://github.com/AnturK/-tg-station/tree/512-test
Commit for completness:
https://github.com/AnturK/-tg-station/commit/ bab233ece16bed1259be13c621cc668da2e7aff9
Both directly with dm.exe and through dreammaker.
DM compiler version 512.1387
loading tgstation.dme
loading interface\skin.dmf
loading map_files\generic\CentCom.dmm
BUG: Out of memory!
BUG: Out of memory!
The terminal process terminated with exit code: 3221225477
aka C0000005 / ACCESS_VIOLATION
ID:2298021
 Sep 26 2017, 8:23 am
|
|||||||||||||
Resolved
| |||||||||||||
Yup, as I suspected the debugger is crapping out before it gets to the point of loading a map file.
I seem to recall /tg having some questionable practices in regards to organization that might impact compiler memory, like avoiding putting things under the same parsing node so that long paths are spelled out each time. (The reason for that is to facilitate searches, I know, but putting the full type paths in comments would be just as effective.) I wonder if changing a few things along those lines would impact your results for the better. It could be that the compiler is choking on the map file in some way, but the project itself is already running very high on memory use so probably some very minor change tipped it over. I'm taking a look to see if there's anything I can improve that might help me get to the bottom of this at my end, or that might possibly lower the memory usage in the next build so that compile goes off without a hitch. Ideally if I can get it down far enough on my end, then maybe I can see the issue in action or cure it altogether. | |
So good news: I managed to pack a struct or two so that the memory was no longer choking on the debugger and I was able to get a crash in the map reading code. That means there's likely something related to the new map code that's breaking on one of SS13's maps, and I should be able to get to the bottom of it--albeit slowly, because it takes a few minutes to get to the point where it's reading the map.
| |
this is likely to do with /tg/'s specialized map format. it's technically complaint on 511 in that it compiles and reads just fine, but not so much on 512 i'd guess.
Edit: maybe not, this was confirmed by our devs to happen with the normal map format. they are confirming all the map files was properly converted now Also, I should point out, the only maps loaded at compile time are the space only zlevel and a mostly space centcom zlevel, the rest are loaded at runtime by /tg/'s map loader Edit2: ya, 511 compiles with under 200mb of memory usage. | |
MSO first guess was right, during the previous test with whitespace removed i skipped one generic map. With that map fixed compilation passes. So this is not real issue.
| |
I suspect there is an error in the 512 map loader, which didn't show up in testing (it was hard to come up with a map to stress test it), and I think I have a potential fix. I'm trying to test the fix, but memory usage in the debugger is still higher than it would be in release and I've been able to reach the map loading stage just intermittently.
| |
Well maybe something good can come out of this.
The special format we use is two part. for the keys, we insert a bunch of new lines so that each item in the key is on its own line, and each var edit on an item is on its own line. for the layout, we do it 1 column at a time. (1,1,1) = a a a a a a a (2,1,1) = a a a a a a a | |
Lummox JR resolved issue with message:
The map reader choked on some complex maps due to a flaw in the new symbol-preserving code. | |
I'll give it a shot though, in case there's something that jumps out like a problem with something being parsed wrong or anything like that. Given the size of your source though, it's likely that it was just already much too close to the limit.