ID:2363503
 
BYOND Version:512.1421
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 60.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Dreamseeker.exe crashed while observing a multiplayer game running with ~15 players. No keyboard input made on crashing client. No obvious triggers on screen. Crash was limited to just my client, no other clients affected at time of crash.
Upon relaunching DreamSeeker by reconnecting to the game, the game was permanently frozen on the first rendered frame and did not recover.
Textbox and UI still functional, but game window was nonresponsive to all mouse input, did not update frames and did not show object names upon hovering.

Windows event log yields the following relevant information (my system language isn't English, I've provided approximate translations):

Failed application name: dreamseeker.exe, version 5.0.512.1421, timestamp 0x5ad11567
Failed module name: byondcore.dll, version 5.0.512.1421, timestamp 0x5ad114f4
Exception code: 0xc0000005 (access violation)
Failure offset: 0x00066c40
Failed PID: 0x620
Failed application starttime: 0x01d3d97b64c0e020


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.)
The problem has been known to occur (personally verified) on 511.1385, 510.1347, and most likely previous versions. I have no idea when it started, though. People from my community say that it's been going on for god-knows how long.

I'm sorry I can't provide much more than this. I tried debugging what I could in VS17, but such an effort is fruitless without source code. If there is any other information I can provide, please let me know.
It looks like this is happening in an icon destructor, so I can't really say more without a test case. A destructor typically only fails because of some earlier corruption.

Since this has been known to occur on older versions it can't be due to recent icon changes, so it's an open question as to what's happening. I strongly doubt that you're running out of memory because of the newer improvements in that area, but I suppose anything's possible.
I see, that does seem like something difficult to track down indeed.
What information should I collect the next time this happens? This is the first time I've seen the full "DreamSeeker.exe has stopped responding" crash, typically it's just the in-game freeze.
Edit: I also doubt it's a memory issue, my machine has plenty of it and Byond never takes up very much at all. I've not noticed any symptoms of a memory leak, and this doesn't happen nearly often enough to seem that plausible
Here's a bit more information for you.
Another crash of the same type described in OP:
Unhandled exception at 0x0FFE7FA5 (byondcore.dll) in dreamseeker.exe: 0xc0000005: Access violation reading location 0x00000001.

Disassembly (including neighbouring lines, no idea if these are relevant):

0FFE7F9C 39 7E 08 cmp dword ptr [esi+8],edi
0FFE7F9F 7E 22 jle 0FFE7FC3
0FFE7FA1 53 push ebx
0FFE7FA2 8B 46 04 mov eax,dword ptr [esi+4]
0FFE7FA5 8B 1C B8 mov ebx,dword ptr [eax+edi*4] (This is the offending line)
0FFE7FA8 85 DB test ebx,ebx
0FFE7FAA 74 10 je 0FFE7FBC
0FFE7FAC 8B CB mov ecx,ebx
0FFE7FAE E8 7D EC FF FF call 0FFE6C30
I would need the offset of that crash to do anything useful with it; the exact memory location isn't very helpful to me. Does the Windows event viewer have the offset?

Although I still suspect the real issue isn't going to be catchable in a trace, based on the previous info. I think it's something I'd have to catch live.
Offset of that particular one was 0x00067fa5. I was thinking that there just isn't enough info in a few addresses to fix it, but hey, any information has to be slightly useful, right?
Your new trace is still inside a destructor, but the parent routine that calls the destructor your earlier trace caught.

The issue at hand is heap corruption, and unfortunately the crash itself is always too late to catch it. Those kinds of issues need to be caught in action.

Given the stability improvements with icons lately, and that your issue goes way back, I suspect there's something your game is doing that a lot of others aren't, whether it be a particular icon operation or something with sound or winsets or whatever. If you can narrow down a particular place in the game this tends to occur more, that might be a big help. Ultimately though what I need is a test case.
In response to Lummox JR
When you say recent icon changes, how recent do you mean? /vg/station has been having a very similar-sounding issue, except only on clients running 511 and newer. We don't currently have it narrowed down enough to open a bug report, but it would help if you could give some places to look.
Wait actually I recognize the name Inorien
You're talking about /vg/station, aren't you?
Are you SURE it happened on 510? Everyone else I've heard has reported that it does not happen except on 511 and 512.
Or at least that it acts differently on 510.
I cannot imagine how, but this seems to have been fixed by 512.1425.