Descriptive Problem Summary:
DreamDaemon.exe server version 511.1384 crashes on startup.
This happens on both windows and linux with exactly the same behavior.

This seems similar to http://www.byond.com/forum/?post=2245438, the crash is at the same memory address and appears to involve appearances. However the circumstances are different, and I have it much more constrained and easier to reproduce this time.

Numbered Steps to Reproduce Problem:

1. Start DreamDaemon.
   
2. In about 15 seconds or so it will segfault (30~ seconds on my laptop)
   

Details

1. The crash is reproducible 100% of the time within 15 seconds from starting DD.
2. The crash occurs at the same line of code on the same object every time.
   - The crash seems to be when reading atom.opacity in /atom/New()
3. I know exactly what changes introduced the crash.
   • On revision f108be6 it doesn't crash.
     
   • One commit later 47dc493 it crashes 100% of the time.
     
   • The diff between these two commits is: https://hastebin.com/iparulirow.diff

I had noticed that /obj/structure/table/update_icon() proc would cause a ton of appearance churn, and thought a quick and easy way to optimize a bit without having to re-write any logic would be to use a mutable_appearance. I'm fairly sure I did the code correctly, but even if I did not, whatever I did wrong shouldn't cause a SEGFAULT right? =p
Anyway, its interesting that although this is the change, it does not actually crash in this proc. This leads me to believe that it might be a similar situation to the problem in my previous thread: Something this proc does (probably assigning src.appearance = ma?) is corrupting appearances (Possibly due to garbage collecting the old appearance?), and the crash occurs the next time something accesses the corruption.
If you see the recent proc calls list, we see that the previous atom to be initialized before the crashing atom was indeed an /obj/structure/table. So that fits this theory.

Logs and traces
In order to get the most information I have run it in valgrind:
Valgrind & Output log: https://hastebin.com/petubugeru.log
Memory map: https://hastebin.com/raw/homuleqope

Source Code
I am hoping that since it happens more reliably and quickly you'll be able run it in a debugger this time. If you clone https://github.com/Leshana/VOREStation-1.git everything is set up to go, just compile vorestation.dme and run vorestation.dmb in dreamdaemon.

Note: If this is indeed the same root cause as my earlier post, I'll close this and append to that post. But enough is different I don't want to make assumptions.