ID:2355722
 
Resolved
Client-side icon operations could cause crashes under rare circumstances.
BYOND Version:512.1415
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 59.0
Applies to:Dream Seeker
Status: Resolved (512.1417)

This issue has been resolved.
Descriptive Problem Summary:
DreamSeeker crashes whenever a mob's icon translates on the screen, but just some mobs, and just sometimes, and often just once.

I thought this was tied into our running issue of "some mobs, when they come onto the screen, crash DreamSeeker".

We have a verb that lets us jump directly to a specific mob. There were reports of crashing around one, and I jumped to it. I did not crash immediately, but as soon as I attempted to move, DreamSeeker crashed. I assume for some reason it couldn't glide the icon across the screen.

The stack seems ... unusual, though. It has a lot of information about JavaScript for some reason. See bottom of report.

Numbered Steps to Reproduce Problem:
It refuses to let me narrow down exactly what causes it, but in general it is:
1) A mob will exist that causes nearby clients to crash
2) Whenever this mob's icon is supposed to move on these client's screens, it crashes them
3) Reconnecting and moving around, even with the mob on screen, will usually not crash again for some time
4) Later, the same mob can crash you again (not sure if later in same session or later another session)

Code Snippet (if applicable) to Reproduce Problem:
Unfortunately it's a very evasive bug and doesn't want me to nail down exactly how to reproduce it.

Expected Results: Not crashing DreamSeeker

Actual Results: Crashing DreamSeeker (once, for a while)

Does the problem occur:
Every time? Or how often? Fairly often on our server (several times per hour), but it depends on what mobs exist
In other games? Not to my knowledge
In other user accounts? Yes, definitely
On other computers? Yes, definitely

When does the problem NOT occur? On test servers, honestly. It seems like it's just a problem when several clients are on at the same time.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Didn't seem occur in 511.

Workarounds:
Reconnecting prevents you from re-crashing for a while, but not forever.


Exception:
The dump itself:
https://www.dropbox.com/s/5pdyi75yvs7ocsk/ dreamseeker.exe_180323_115601.dmp?dl=0

This exception is all fairly normal, but...
eax=00839a78 ebx=00839b3c ecx=00000003 edx=00000000 esi=77323d38 edi=5cfe6d48
eip=752508b2 esp=00839a78 ebp=00839ad0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200216
KERNELBASE!RaiseException+0x62:
752508b2 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:00839acc=57436069


The rest of the stack is not... how does Javascript relate to Byond? How is it tied into this?
 # ChildEBP RetAddr
00 00839ad0 7735a222 KERNELBASE!RaiseException+0x62
01 00839b18 5cd86256 msvcrt!_CxxThrowException+0x72
02 00839b5c 5cd8605c jscript9!Js::JavascriptExceptionOperators::ThrowExceptionObjectInternal+0xc1
03 00839b78 5cd7e07d jscript9!Js::JavascriptExceptionOperators::Throw+0x4a
04 00839bc4 579890d4 jscript9!CJavascriptOperations::ThrowException+0x9d
05 00839c04 57ced14e mshtml!CFastDOM::ThrowDOMError+0xc7
06 00839c28 5ce56784 mshtml!`CBackgroundInfo::Property'::`7'::`dynamic atexit destructor for 'fieldDefaultValue''+0xebade
07 00839c98 5ce110ae jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x194
08 00839eb8 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x85e
09 0083a014 05190f29 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
WARNING: Frame IP not in any known module. Following frames may be wrong.
0a 0083a020 5ce13050 js!Anonymous function [https://code.jquery.com/jquery-1.11.3.min.js @ 2,10704]
0b 0083a240 5ce0feb0 jscript9!Js::InterpreterStackFrame::Process+0x2800
0c 0083a278 5ce152f8 jscript9!Js::InterpreterStackFrame::OP_TryCatch+0x49
0d 0083a48c 5ce0fdad jscript9!Js::InterpreterStackFrame::Process+0x4aa8
0e 0083a4c4 5ce1714f jscript9!Js::InterpreterStackFrame::OP_TryFinally+0x36
0f 0083a6d8 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x68ff
10 0083a80c 05190f51 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
11 0083a818 5ce110ae js!ja [https://code.jquery.com/jquery-1.11.3.min.js @ 2,7586]
12 0083aa38 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x85e
13 0083abac 05190f61 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
14 0083abb8 5ce58783 js!ga.setDocument [https://code.jquery.com/jquery-1.11.3.min.js @ 2,8537]
15 0083abfc 5ce0dd99 jscript9!Js::JavascriptFunction::CallFunction<1>+0x93
16 0083ac20 5ce0e469 jscript9!Js::InterpreterStackFrame::OP_CallCommon >+0x89
17 0083ac44 5ce0f3f5 jscript9!Js::InterpreterStackFrame::OP_ProfileReturnTypeCallCommon >+0x1a
18 0083ac64 5ce14814 jscript9!Js::InterpreterStackFrame::OP_ProfiledReturnTypeCallI+0x2a
19 0083ae78 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x3fc4
1a 0083b1d4 05190fa1 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
1b 0083b1e0 5ce58783 js!Anonymous function [https://code.jquery.com/jquery-1.11.3.min.js @ 2,21135]
1c 0083b22c 5ce0dd99 jscript9!Js::JavascriptFunction::CallFunction<1>+0x93
1d 0083b250 5ce0e469 jscript9!Js::InterpreterStackFrame::OP_CallCommon >+0x89
1e 0083b274 5ce0f3f5 jscript9!Js::InterpreterStackFrame::OP_ProfileReturnTypeCallCommon >+0x1a
1f 0083b294 5ce14814 jscript9!Js::InterpreterStackFrame::OP_ProfiledReturnTypeCallI+0x2a
20 0083b4a8 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x3fc4
21 0083bc9c 05190fd9 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
22 0083bca8 5ce110ae js!Anonymous function [https://code.jquery.com/jquery-1.11.3.min.js @ 2,4392]
23 0083bec8 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x85e
24 0083c00c 05190fe1 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
25 0083c018 5ce110ae js!Anonymous function [https://code.jquery.com/jquery-1.11.3.min.js @ 2,207]
26 0083c238 5ce0711a jscript9!Js::InterpreterStackFrame::Process+0x85e
27 0083c364 05190fe9 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1fa
28 0083c370 5ce58783 js!Global code [https://code.jquery.com/jquery-1.11.3.min.js @ 2,2]
29 0083c3b4 5cd973ed jscript9!Js::JavascriptFunction::CallFunction<1>+0x93
2a 0083c428 5cd97559 jscript9!Js::JavascriptFunction::CallRootFunctionInternal+0xb5
2b 0083c480 5ce2d75f jscript9!Js::JavascriptFunction::CallRootFunction+0x4d
2c 0083c4c8 5cda4275 jscript9!ScriptSite::CallRootFunction+0x42
2d 0083c50c 5cd812ed jscript9!ScriptSite::Execute+0xd7
2e 0083c59c 5cd82188 jscript9!ScriptEngine::ExecutePendingScripts+0x1bd
2f 0083c634 5cd8224a jscript9!ScriptEngine::ParseScriptTextCore+0x345
30 0083c690 579af75a jscript9!ScriptEngine::ParseScriptText+0x5a
31 0083c6d0 579af6a3 mshtml!CActiveScriptHolder::ParseScriptText+0xaa
32 0083c728 57841519 mshtml!CJScript9Holder::ParseScriptText+0x63
33 0083c798 57843401 mshtml!CScriptCollection::ParseScriptText+0x181
34 0083c884 5784294f mshtml!CScriptData::CommitCode+0x2ec
35 0083c904 578426ba mshtml!CScriptData::Execute+0x23f
36 0083c924 57a6f7f9 mshtml!CHtmScriptParseCtx::Execute+0xfa
37 0083c978 57a89b54 mshtml!CHtmParseBase::Execute+0x229
38 0083c994 57a892b2 mshtml!CHtmPost::Broadcast+0x1e4
39 0083cac4 578313ed mshtml!CHtmPost::Exec+0x1b2
3a 0083cae4 578312e5 mshtml!CHtmPost::Run+0x3d
3b 0083cb04 57831246 mshtml!PostManExecute+0x60
3c 0083cb18 57a92d16 mshtml!CPostManager::PostManOnTimer+0x76
3d 0083cb90 578ea4a4 mshtml!GlobalWndOnMethodCall+0x206
3e 0083cbdc 74dce0bb mshtml!GlobalWndProc+0xe4
3f 0083cc08 74dd8849 user32!_InternalCallWinProc+0x2b
40 0083cc2c 74ddb145 user32!InternalCallWinProc+0x20
41 0083ccfc 74dd833a user32!UserCallWinProcCheckWow+0x1be
42 0083cd44 74dbf38b user32!CallWindowProcAorW+0xd4
43 0083cd5c 5e383a21 user32!CallWindowProcA+0x1b
44 0083cde0 74dce0bb mfc120!_AfxActivationWndProc+0x132 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 495]
45 0083ce0c 74dd8849 user32!_InternalCallWinProc+0x2b
46 0083ce30 74ddb145 user32!InternalCallWinProc+0x20
47 0083cf00 74dc90dc user32!UserCallWinProcCheckWow+0x1be
48 0083cf6c 74dc38c0 user32!DispatchMessageWorker+0x4ac
49 0083cf74 5e372d8c user32!DispatchMessageA+0x10
4a 0083cf84 5e387f80 mfc120!AfxInternalPumpMessage+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183]
4b 0083cfa8 5e32a745 mfc120!CWnd::RunModalLoop+0xc6 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4644]
4c 0083cfc0 5e32a9c8 mfc120!CWnd::CreateRunDlgIndirect+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 474]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for dreamseeker.exe -
4d 0083d014 00d5264e mfc120!CDialog::DoModal+0x109 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 633]
4e 0083f8b4 5e396300 dreamseeker+0x3264e
4f 0083f8c8 00d8290e mfc120!AfxWinMain+0x47 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
50 0083f914 76c98654 dreamseeker+0x6290e
51 0083f928 77b24a77 kernel32!BaseThreadInitThunk+0x24
52 0083f970 77b24a47 ntdll!__RtlUserThreadStart+0x2f
53 0083f980 00000000 ntdll!_RtlUserThreadStart+0x1b
</1></1></1></1></1></ 1></1></1></1></1>
Recreated the issue by moving onto the same screen as the mob again, and our friend DMIcon:clear again:
eax=73656420 ebx=256909d0 ecx=256909d0 edx=12b03d90 esi=256909d0 edi=00000000
eip=5de982d5 esp=007fbb90 ebp=007fbcac iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210206
byondcore!DMIcon::clear+0x15:
5de982d5 8b1cb8          mov     ebx,dword ptr [eax+edi*4] ds:002b:73656420=????????


 # ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00 007fbcac 5de8daa4 byondcore!DMIcon::clear+0x15
01 007fbcd4 5dfbfcbd byondcore!ByondHttpServerHandler::HandleRequest+0x1594
02 007fbd10 5dfbfcbd byondcore!ClassyCallback::Callback+0xd
03 007fbdb4 5de79aae byondcore!ClassyCallback::Callback+0xd
04 007fbdcc 5de6b918 byondcore!FilterChain::Interpolate+0x22e
05 007fc234 5de6b858 byondcore!SharedFilter::operator!=+0x66c8
06 007fc304 5de5377b byondcore!SharedFilter::operator!=+0x6608
07 007fcba8 5de531a4 byondcore!StyleInfo::operator=+0xf4b
08 007fcbbc 5e0006ba byondcore!StyleInfo::operator=+0x974
09 007fcbd4 5dffe9c9 byondcore!StringToFile::LockBuffer+0x150a
0a 007fcc18 5de542b8 byondcore!ByondHttpServerLink::WriteBuffer+0xcf9
0b 007fcc2c 5e0002c8 byondcore!DungServer::GetServerPort+0x5b8
0c 007fcc54 5dffed25 byondcore!StringToFile::LockBuffer+0x1118
0d 007fcc64 5e010dc1 byondcore!ByondHttpServerLink::WriteBuffer+0x1055
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for dreamseeker.exe -
0e 007fcc8c 00d70302 byondcore!SocketLib::Event_io+0x1f1
0f 007fccbc 5e38540a dreamseeker+0x50302
10 007fcd88 5e3850ca mfc120!CWnd::OnWndMsg+0x31d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2272]
11 007fcda8 5e3836ad mfc120!CWnd::WindowProc+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094]
12 007fce18 5e3838cf mfc120!AfxCallWndProc+0x99 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285]
13 007fce38 5e283a36 mfc120!AfxWndProc+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434]
14 007fce74 74dce0bb mfc120!AfxWndProcBase+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 299]
15 007fcea0 74dd8849 user32!_InternalCallWinProc+0x2b
16 007fcec4 74ddb145 user32!InternalCallWinProc+0x20
17 007fcf94 74dc90dc user32!UserCallWinProcCheckWow+0x1be
18 007fd000 74dc38c0 user32!DispatchMessageWorker+0x4ac
19 007fd008 5e372d8c user32!DispatchMessageA+0x10
1a 007fd018 5e387f80 mfc120!AfxInternalPumpMessage+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183]
1b 007fd03c 5e32a745 mfc120!CWnd::RunModalLoop+0xc6 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4644]
1c 007fd054 5e32a9c8 mfc120!CWnd::CreateRunDlgIndirect+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 474]
1d 007fd0a8 00d5264e mfc120!CDialog::DoModal+0x109 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 633]
1e 007ff948 5e396300 dreamseeker+0x3264e
1f 007ff95c 00d8290e mfc120!AfxWinMain+0x47 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
20 007ff9a8 76c98654 dreamseeker+0x6290e
21 007ff9bc 77b24a77 kernel32!BaseThreadInitThunk+0x24
22 007ffa04 77b24a47 ntdll!__RtlUserThreadStart+0x2f
23 007ffa14 00000000 ntdll!_RtlUserThreadStart+0x1b
Please get me a test case and tell me exactly what steps I need to reproduce it. Since this is now happening for you reliably, I should be able to get to the bottom of it right away.
I'm trying. I've narrowed it down to some very specific steps, but they're still very specific in terms of SS13. In terms of Byond native function calls it's still very broad.

I can definitely give you an SS13 test case you can reproduce it in about once every two minutes, but I doubt I can give you a 'clean project' test case. I'm told that you won't/can't troubleshoot full SS13 compiled projects, though, due to the memory use? Or did you want me to send one anyway?

Server takes about 800mb for us, by-the-by.
Actually I guess it's a client crash, what'm I thinking. I'll zip up a server that you can use to reproduce it and send it to you in a private message (the zip will include our player's save data which I'd rather not publish, as their custom character is definitely one that causes crashes).
Sent it to you in forum PM.
My main issue with testing SS13 cases server-side is in big builds like /tg they often overwhelm the debugger. But it can still be useful sometimes to have such a test case available. If this is a client issue then it should be easier to diagnose though.
Were you able to get this to crash on your end? Sort of a large issue for us, but also just concerned about the usefulness of the test I sent and that it actually does let you reproduce the issue.
I sent a response to your message yesterday. Because your test case requires two machines, it's a non-starter. I can't test that way. Even requiring two login keys is a bit much, although not as insurmountable a problem (just super annoying).

I asked if you could add a verb to load the player without needing a login, so I could just skip straight to the observation part that has the actual crash. Or if you could show me what to add, I could try adding that myself.

It seems to me, based on your description, that the crash involves observing this particular mob, so loading up that mob as a dummy should be adequate to produce the crash without requiring a second machine or second login.
Okay, but, it will not crash if you are playing the mob for whatever reason, I assume that the character setup preview somehow caches it on your machine in a way that prevents crashing, or, otherwise in some way that prevents it.

Nobody playing the mob ever crashes. It's always people playing other mobs, as soon as the crash-mob attempts to come into their view, their client crashes.

For all I know, making a verb to spawn said mob will put your client in the 'protected' state that whoever is playing the mob gets into by doing whatever it does in that state.

Maybe just try it on one machine? It may still work. Join as the crash mob, then quit. Change logins, clear your cache (by deleting the contents of the folder), and then rejoin and use the observe instructions.
It does work on one machine, it looks like, but you do need two accounts otherwise you will just go back into the original mob and be fine.

So join as crash mob per directions sent, quit, logout of byond, log back in with second account, clear cache (still fairly sure only deleting all the files does it), rejoin, observe, jump-to-mob.
You could just make something to detach from the mob by nulling its ckey var
That might work too, though still need to clear the cache. The cache is poisoned (or, well, what's the opposite of poison? panacea'd?) when you join the game as that mob, and it will not crash until cleared.
Is there an easy verb you could throw together that would just load the mob and not attach a ckey?
Actually for whatever reason, I'm able to crash just by doing Observe which is not something I've been able to do in the past.

Just click Setup Character, make sure you have that mentioned character loaded, and click Observe in the menu. Enjoy the crash. If you don't crash, quit, clear cache, rejoin.
Okay, so here's where we're at:

After much, much wrestling with the code and removing a lot of IsGuestKey() checks that were massively getting in my way, I was able to reproduce the problem by going to Setup Character, then Observe.

The problem has to do with how DDMI files (dynamic DMI, i.e. client-side icon operations) are loaded. Apparently the logic in that section is really not as bulletproof as it should have been, but the issue doesn't show up in most cases.

I'm now going back over the DDMI code to see how I can change the way things load, so this will actually function as intended. I haven't touched this code meaningfully in a while so it'll take a bit to figure it out, but I'm on the case.
Great to hear, glad you were able to at least see where in the code the problem is rooted.
potentially fixes ID:2024837 as last i remembered before we disabled minimap generation to avoid the crash was that it was related to some memory runaway with modifying icons that didn't happen in local testing the related code.
Lummox JR resolved issue with message:
Client-side icon operations could cause crashes under rare circumstances.