DCS MP Crash with Script Engine

Hi ED,

Since the latest OB update, we have a complete DCS crash when an AI plane lands and then taxi to parking and shuts its engine down. Tried on both servers and client PC's, same on different systems.

Isolated it to the MOOSE function: InitRepeatOnEngineShutDown.

When using InitRepeatOnLanding DCS does not crash.

I know MOOSE it not from ED, but still VERY widely used and it would be nice if you guys can have a look at it anyway.

This did/does not happen on the previous OB build.

Attached you will find the test mission/logs/DCS crash report files.

Track file is NOT generated due to crash.

Hope to hear a response as this function is used a lot.

MOOSE_Crash.rar

Can confirm, exactly that same error here. Nothing in MOOSE has changed and can confirm the night before the patch it worked flawlessly (was helping someone debug something around the InitRepeatOnEngineShutdown and used it perfectly in about a dozen tests). Next day, patch, boom, this.

We are letting FlightControl know so he can double tap on his side, but unless ED changed the way it works, there should be no issues with MOOSE

dcs.log-20181221-234413.zip

Not asking ED to TS MOOSE, asking ED to take a look at what they changed around the engine shutting down or spawning of an aircraft. MOOSE hasn't changed anything in about a month (the release version, which is what I'm using, and have been for the last month) and it worked, again, FLAWLESSLY for me UNTIL the patch. Now it crashes when the engine shuts down, the plane is removed from the map, and new one is to be created. Somewhere in there. Not sure why MOOSE would have to TS something when they've changed nothing? (but they have been informed of the issue so they can look at MOOSE)

*edit* Was the log even looked at? It's an interesting one - Separated part of it

2018-12-21 23:25:38.687 INFO EDTERRAINGRAPHICS41: surface5 gc() 10.993911 ms

2018-12-21 23:25:40.122 INFO SCRIPTING: 10954( 10856)/I: DATABASE00003._RegisterGroupTemplate({[Coalition]=0,[Category]=0,[Group]=IRAN#001,[Country]=34,[units]={[1]=IRAN#001-01,},})

2018-12-21 23:25:40.125 INFO SCRIPTING: 10765( 10867)/I: DATABASE00003.AddGroup({[1]=Add GROUP:,[2]=IRAN#001,})

2018-12-21 23:27:25.542 INFO SCRIPTING: 10954( 10856)/I: DATABASE00003._RegisterGroupTemplate({[Coalition]=0,[Category]=0,[Group]=IRAN#001,[Country]=34,[units]={[1]=IRAN#001-01,},})

2018-12-21 23:27:25.545 INFO EDCORE: try to write dump information

2018-12-21 23:27:25.548 INFO EDCORE: # -------------- 20181221-232726 --------------

2018-12-21 23:27:25.549 INFO EDCORE: E:\GAMES-SSD\DCS\DCS World OB\bin\DCS.exe

2018-12-21 23:27:25.549 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 8978333C 00:00000000

2018-12-21 23:27:25.550 INFO EDCORE: SymInit: Symbol-SearchPath: '.;E:\GAMES-SSD\DCS\DCS World OB;E:\GAMES-SSD\DCS\DCS World OB\bin;C:\WINDOWS;C:\WINDOWS\system32;SRVC:\websymbolshttp://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'Game'

2018-12-21 23:27:25.550 INFO EDCORE: OS-Version: 10.0.17134 () 0x300-0x1

2018-12-21 23:27:26.122 INFO EDCORE: 0x00007FF68978333C (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.122 INFO EDCORE: 0x00007FF689782E95 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.123 INFO EDCORE: 0x00007FF6897C4775 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.123 INFO EDCORE: 0x00007FF68977AD5C (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.123 INFO EDCORE: 0x00007FFBC7BF271A (World): (function-name not available) + 0x0

2018-12-21 23:27:26.123 INFO EDCORE: 0x00007FFBC7BF2C06 (World): (function-name not available) + 0x0

2018-12-21 23:27:26.123 INFO EDCORE: 0x00007FF689A31986 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689A3FF4E (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689A18530 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689693DD5 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689695C09 (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689BCC44F (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FF689BCC44F (DCS): (function-name not available) + 0x0

2018-12-21 23:27:26.124 INFO EDCORE: 0x00007FFBCEF93034 (KERNEL32): BaseThreadInitThunk + 0x14

2018-12-21 23:27:26.125 INFO EDCORE: 0x00007FFBCF553691 (ntdll): RtlUserThreadStart + 0x21

2018-12-21 23:27:26.342 INFO EDCORE: Minidump created.

I peaked at a couple other logs from people, and will eat my words - I see where MODs are considered and why (makes sense in other words) - I still don't feel that's the issue. Other than MOOSE, I run no mods, and MOOSE is just a scripting language that works off of DCS's own API's. I wont speak further to that as I'm not smart enough to.

But, what I will speak too is this is obviously something in the ED code/programming. When nothing else changes, the only thing it can be is the ONE thing that did change - DCS World

It would be up to the creators of MOOSE to troubleshoot this issue, MOOSE is not officially supported by ED.

MOOSE is just a long lua script where eventually always a DCS scripting engine function is called. In this case coalition.addGroup after the old group has be despawned via destroy.

If a call to such a function is causing an access violation in EDCORE this is at least sloppy programming if not a bug on the DCS side. This would be the case for any call of a DCS scripting function as this should never result in a CTD even if the passed function arguments were wrong.

Therefore, it might be worth looking into it, if time permits(!), since stuff like this usually hints to a bigger problem. (Especially since this has been working for ages and just with the the latest 2.5.4 OB causes a CTD.)

Nine move it back to the crashes section since it is a crash caused by the scripting engine. Stuff like this happens from time to time when doing certain scripts when units are in a certain state.

funkyfranky, so is it using the engine shutdown event to trigger destroying the old group and then spawning a new group as part of the same function call with as little time in between as possible?

I remember there used to be a crash when destroying a unit when used in conjunction with the land event.

funkyfranky, so is it using the engine shutdown event to trigger destroying the old group and then spawning a new group as part of the same function call with as little time in between as possible?

Yes, and I'll try to narrow it down a bit more if I can. I know this not so easy to debug without further info.

Got it to crash with just this:

function addEventHandler(f) --id is optional!
	local handler = {}
	handler.id = 1
	handler.f = f
	function handler:onEvent(event)
		log:info(event)
           self.f(event)
	end
	world.addEventHandler(handler)
	return handler.id
end

function myEvent(_event)
    if _event.id == 18 then
       Unit.getGroup(_event.initiator):destroy()
   end
end

addEventHandler(myEvent)

Just destroying each unit 1 at a time doesn't crash. Getting the group and destroying the group causes the crash.

Suggested workaround is to schedule removing the group at a later point in time.

Got it to crash with just this:

[...]

Just destroying each unit 1 at a time doesn't crash. Getting the group and destroying the group causes the crash.

 

Suggested workaround is to schedule removing the group at a later point in time.

Thanks, Grimes! That makes sense and explains it. Very professional and helpful as always :thumbup:

Great work Grimes, so this should be put back in the Bug section ?

Thanks Grimes, happy to see help coming from you on this topic. Now I hope ED will put it back in the actual DCS bug section and get this sorted.

Rocking as always Grimes! Thanks man!

So in ED terms, calling GROUP:destroy() can cause a DCS crash. (ED API)

So in ED terms, calling GROUP:destroy() can cause a DCS crash. (ED API)

Only when called during engine shutdown, or at least the event handler of event shutdown. It works normally in other circumstance. At any rate the bug has been reported, hopefully since it is a crash it might be resolved quickly.

It should be very easy to circumvent this as it is restricted to the engine shutdown event.

Thanks again to all testers and moderators involved!

I never had a chance to look into this fully even in the previous update. As far as I can tell there was an issue in the previous update that broke the OnEngineShutdown but it didn’t cause a DCS crash. It just wouldn’t delete the group.

So I think they can look into what changes they made in the last two builds. Got bad two builds ago, got even worse in the last build.

Thanks for doing a proper test Grimes for this latest one.

Seems that this bug is also affecting RAT, I've had to disable random traffic on my missions :(

Does anyone know if the new Jan2019 update fixes the crash caused by InitRepeatOnEngineSHutDown()?

Thanks

Apparently this crash with InitRepeatOnEngineShutdown was fixed by funkyfranky

https://github.com/FlightControl-Master/MOOSE/issues/1076

in the development branch of Moose. Is this a different Moose/lua file? Where would I get this from?

Thanks

Yes the crash on destroying a group with engine shutdown event was fixed in the latest patch.

I'm still getting crashes happening..

Oh some further info if it helps Grimes or the like.. those are all using the repeat on landing (not engine shut down) and it's happening with Heli's and Planes alike

2019-01-18 11:36:10.719 INFO    Scripting: event:type=land,target=Gelendzhik,initiator=RECON 1#001-01,place=Gelendzhik,t=43014.861,placeDisplayName=Gelendzhik,initiatorMissionID=1000289,
2019-01-18 11:36:10.719 INFO    EDCORE: try to write dump information
2019-01-18 11:36:10.730 INFO    EDCORE: # -------------- 20190118-113611 --------------
2019-01-18 11:36:10.742 INFO    EDCORE: D:\DCS World OpenBeta\bin\WorldGeneral.dll
2019-01-18 11:36:10.750 INFO    EDCORE: # C0000005 ACCESS_VIOLATION at 1B4245F4 00:00000000
2019-01-18 11:36:10.784 INFO    EDCORE: SymInit: Symbol-SearchPath: '.;D:\DCS World OpenBeta;D:\DCS World OpenBeta\bin;C:\Windows;C:\Windows\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'root'
2019-01-18 11:36:10.792 INFO    EDCORE: OS-Version: 10.0.14393 () 0x10-0x3
2019-01-18 11:36:12.513 INFO    EDCORE: 0x00007FFB1B4245F4 (WorldGeneral): Sound::Source::play_once + 0x4
2019-01-18 11:36:12.525 INFO    EDCORE: 0x00007FF6085E0CB0 (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.534 INFO    EDCORE: 0x00007FF6085F2DFA (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.536 INFO    EDCORE: 0x00007FF6085AB30F (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.537 INFO    EDCORE: 0x00007FFB290A2720 (World): (function-name not available) + 0x0
2019-01-18 11:36:12.538 INFO    EDCORE: 0x00007FFB290A2C55 (World): (function-name not available) + 0x0
2019-01-18 11:36:12.539 INFO    EDCORE: 0x00007FF6088626A6 (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.540 INFO    EDCORE: 0x00007FF608870C4E (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.541 INFO    EDCORE: 0x00007FF6088491B0 (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.542 INFO    EDCORE: 0x00007FF6084C3DD5 (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.544 INFO    EDCORE: 0x00007FF6084C5C30 (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.545 INFO    EDCORE: 0x00007FF6089FDFEF (DCS): (function-name not available) + 0x0
2019-01-18 11:36:12.546 INFO    EDCORE: 0x00007FFB32F78364 (KERNEL32): BaseThreadInitThunk + 0x14
2019-01-18 11:36:12.547 INFO    EDCORE: 0x00007FFB33CCE851 (ntdll): RtlUserThreadStart + 0x21

Seeing the same thing in our crash logs on the CSG-1 server. I believe we're using the latest release of MOOSE, but I'll check.

Can anyone post a link to the patch or update to Moose that is supposed to fix this? All I can find is 2.4.13 that corrects a documentation issue.

https://github.com/FlightControl-Master/MOOSE/releases

mark it's not an issue with MOOSE it's an issue with DCS, the SPAWN commands haven't changed in months but there what is causing the crash...

something as simple as putting a C-17 in have it late activate and running

C17TEST = SPAWN:New("Test Group"):InitLimit(1,999):InitRepeatOnLanding():SpawnScheduled(5,0.75)

will have DCS crash when the units deleted on landing So by the looks of it while ED may have fixed one bug they introduced another. (This was functioning fine last build) and nothing has changed in moose.

So @Grimes On Engine shut down is working, on landing is crashing now. Just so your aware..