Client version: Falcon BMS 4.34u4.
Theater version: Cougar’s ITO 4.34.3.
I realize this is an unofficial, unsupported theater. But during the last two UOAF multiplayer events, I experienced a crash-to-desktop. They both were the same error, an attempt to dereference a null pointer inside of ATCBrain::RemoveTraffic.
I am posing this for two reasons:
Possibly this indicates a misconfiguration in the ITO theater data files somewhere. In that case it would be great to understand what the offending data file is so that it could be fixed.
Possibly this is just an issue with the code. In that case I thought the developers would want to know about it.
================================== CRASHLOG =====================================
Falcon BMS.exe caused an EXCEPTION_ACCESS_VIOLATION in:
0000000004A991A9 Falcon BMS.exe, ATCBrain::RemoveTraffic()+57 byte(s), d:\wip\bms\svn\code-4.34\campaign\camplib\atcbrain.cpp, line 9596+2 byte(s)
Exception handler called in UnhandledExceptionHandler.
Read from location 00000000ffffffff caused an access violation.
Bytes at CS:RIP: 39 19 75 06 39 79 04 0F 94 C0 85 C0 75 0B 48 8B
Registers:
RAX=0x0000000000000000 RBX=0x000000ff000082e2 RCX=0x90000a0035fdba65 RDX=0x000000ff000082e2
RSI=0x00000000248d7360 RDI=0x00000000000000ff RBP=0x0000000024d1f1f9 RSP=0x0000000024d1f160
RIP=0x0000000004a991a9 FLG=0x0000000000010246
R8=0x00000000ffffffff R9=0x90000a0035fdba65 R10=0x3ff0000000000000 R11=0x0000000024d1f130
R12=0x000000002d1f2430 R13=0x0000000000000002 R14=0xffffffffffffffff R15=0x00000000c00c2440
CS=0x0033 DS=0x002B SS=0x002B ES=0x002B FS=0x0053 GS=0x002B
Call Stack:
0033:0000000004A991A9 Falcon BMS.exe, ATCBrain::RemoveTraffic()+57 byte(s), d:\wip\bms\svn\code-4.34\campaign\camplib\atcbrain.cpp, line 9596+2 byte(s), Parameters(0x000000000F3EA980 0x00000000000082E2 0x000000004A088050 0x0000000015744560)
0033:0000000004B061CA Falcon BMS.exe, FalconATCCmdMessage::Process()+5530 byte(s), d:\wip\bms\svn\code-4.34\falclib\messages\atccmdmsg.cpp, line 596, Parameters(0x00000000C00C2440 0x0000000049C10DE6 0x0000000049FA6F3C 0x0000000000000000)
0033:00000000049F6642 Falcon BMS.exe, VuMessage::Dispatch()+98 byte(s), d:\wip\bms\svn\code-4.34\vu2\src\vuevent.cpp, line 1077, Parameters(0x00000000C00C2440 0x0000000000000006 0x00000000C00C2440 0x0000000000000006)
0033:00000000049F55AB Falcon BMS.exe, VuMessageQueue::DispatchAllMessages()+219 byte(s), d:\wip\bms\svn\code-4.34\vu2\src\vuevent.cpp, line 413+171 byte(s), Parameters(0x0000000000000001 0x0000000024D1F3C0 0x0000000004C76DB8 0x0000000000000000)
0033:00000000049EAD69 Falcon BMS.exe, VuMainThread::Update()+8793 byte(s), d:\wip\bms\svn\code-4.34\vu2\src\vu.cpp, line 1500, Parameters(0x0000000011E2CE10 0x0000000004C76B70 0x0000000000000000 0x0000000000000004)
0033:00000000048DE072 Falcon BMS.exe, SimulationLoopControl::Loop()+1794 byte(s), d:\wip\bms\svn\code-4.34\sim\simloop\simloop.cpp, line 504+128 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000004206F44F)
0033:00000000044E900D Falcon BMS.exe, ThreadUnhandledExceptionWrapper()+109 byte(s), d:\wip\bms\svn\code-4.34\falclib\ehandler.cpp, line 1585+5 byte(s), Parameters(0x0000000000000000 0x000000002415DA50 0x0000000000000000 0x0000000000000000)
0033:0000000004B851FD Falcon BMS.exe, thread_start<unsigned int="" (__cdecl*)(void="" *="" __ptr64)="">()+93 byte(s), d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp, line 115+5 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:0000000048D37BD4 KERNEL32.DLL, BaseThreadInitThunk()+20 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:000000004944CED1 ntdll.dll, RtlUserThreadStart()+33 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)</unsigned>
0000000004A9919B mov r9,qword ptr [rax+r14*8]
0000000004A9919F mov rcx,r9
0000000004A991A2 test r9,r9
0000000004A991A5 je ATCBrain::RemoveTraffic+0B4h (04A99224h)
0000000004A991A7 xor eax,eax
0000000004A991A9 cmp dword ptr [rcx],ebx
The access violation is an attempt to dereference the contents of RCX, which is the invalid address 0x90000a0035fdba65 (the cmp instruction). How did rcx get that value? By dereferencing some offset of rax. That register is currently 0, so this offset points to a bogus memory location.
I believe this is set from offset 0x30 from atcBrain, which should be the struct member inboundQueue:
So in summary, it looks like ATCBrain::RemoveTraffic is dereferencing an offset from atcBrain.inboundQueue, when atcBrain.inboundQueue happens to be null.
Full crash dumps hosted on google drive.
Thanks!