Is it me (bad scripting) or a memory leak?

[prccowboy]

While DCS is mostly stable for me flying the "vanilla" missions/campaigns (like Georgian Hammer or Red Flag), I've gotten a little bored with them and have been attempting to build my own but I consistently see crashes now (usually after 20-60 minutes "game" time). It has been a bit frustrating because I don't know if it is my scripts/mission building that is causing the instability or something else (like memory leaks). I don't think any of my scripts are firing when it crashes (most run within the first few seconds) and I don't see anything in the logs that indicate a script error or hardware faults but I am open to the idea that maybe it's on my side. The missions I am creating are not "heavy" - usually about 300 total units (half that being unused late activation groups for a dynamic spawning pool)

 

Nevertheless, whenever I see a crash, there is usually high memory usage. I have 16GB RAM with pagefiles usually set at 16 or 32GB. In one of my recent crashes the memory usage was 9.2GB used and 21.4GB!!! (of 47.9) committed with 6.6GB cached. However, most crashes seem to happen around 12GB committed. (memory commits are at about 1.7GB without DCS running)

 

What I'm looking for is feedback whether or not it is something I should be looking at on my side or if it is something outside my control (like a known memory leak). I'm attaching some snippets from my last 5 crashes (what happens immediately before the crash). A common error seems to be related to tracer model json files...

 

Thanks in advance for any feedback (this has been really frustrating my attempts at mission building)

 

edit: changed thread name because its not a memory leak, but possibly a different bug

 

 

2018-04-06 03:20:34.836 INFO EDTERRAINGRAPHICS41: forestDistanceFactor has been changed to 1.000000. Update lod buffers.

2018-04-06 03:20:34.836 INFO EDTERRAINGRAPHICS41: InstanceManager2::updateObjectDeclBuffer()

2018-04-06 03:20:34.837 INFO EDTERRAINGRAPHICS41: InstanceManager2::updateObjectLodDeclBuffer()

2018-04-06 03:24:22.390 INFO EDCORE: try to write dump information

 

2018-04-06 02:19:33.254 INFO EDTERRAINGRAPHICS41: InstanceManager2::updateObjectDeclBuffer()

2018-04-06 02:19:33.255 INFO EDTERRAINGRAPHICS41: InstanceManager2::updateObjectLodDeclBuffer()

2018-04-06 02:23:09.466 ERROR VFS: Can't open file //models/tracer_bullet_green.edm.json.

2018-04-06 02:23:12.215 INFO EDCORE: try to write dump information

 

2018-04-06 01:26:08.738 ERROR VFS: Can't open file //models/tracer_bullet_red.edm.json.

2018-04-06 01:28:20.123 INFO EDCORE: try to write dump information

 

2018-04-05 23:47:04.584 ERROR VFS: Can't open file //models/tracer_bullet_red.edm.json.

2018-04-05 23:47:23.668 INFO TERRAIN: lObjectFire::lObjectFire for building id=111151555

2018-04-05 23:47:31.410 ERROR VFS: Can't open file //models/tracer_bullet_green.edm.json.

2018-04-05 23:48:00.364 INFO TERRAIN: lObjectFire::lObjectFire for building id=220595505

2018-04-05 23:48:00.384 WARNING LOG: 1 duplicate message(s) skipped.

2018-04-05 23:48:00.384 INFO TERRAIN: lObjectFire::lObjectFire for building id=220595504

2018-04-05 23:48:00.389 INFO TERRAIN: lObjectFire::lObjectFire for building id=220595505

2018-04-05 23:48:32.500 WARNING LOG: 3 duplicate message(s) skipped.

2018-04-05 23:48:32.500 INFO TERRAIN: lObjectFire::lObjectFire for building id=220530750

2018-04-05 23:48:56.856 INFO EDCORE: try to write dump information

 

2018-04-05 23:27:55.749 ERROR VFS: Can't open file //models/tracer_bullet_red.edm.json.

2018-04-05 23:28:09.285 INFO TERRAIN: lObjectFire::lObjectFire for building id=111150060

2018-04-05 23:29:01.859 WARNING LOG: 2 duplicate message(s) skipped.

2018-04-05 23:29:01.859 INFO EDCORE: try to write dump information

 

Edited April 8, 2018 by prccowboy

[BIGNEWY]

If you have your full dcs.log please attach it for the devs so they can see it. ( change the .log to a .txt and then attach )

 

from the section of log you have here I can see

 

ERROR VFS: Can't open file //models/tracer_bullet_red.edm.json.

 

this is reported, basically when there is lots of tracer fire, this error happens.

[prccowboy]

ok, here is one of my full logs (I have a lot to choose from). I think this is one of the "typical" crashes but not the one where it hit 21GB memory committed (I think I still have that one too if you want it)

 

dcs.20180406-012820.txt

 

postscript: I will attempt to actually fly one of my latest mission builds today and send a new log if I have another crash. Mostly I have been just testing the missions from ME and letting them run at 5x speed to check my scripts.

Edited April 6, 2018 by prccowboy

[prccowboy]

OK, here is another example. I just tried flying one of my WIP mission test builds and had another crash. I deleted the fxo and metashader folders before the mission (which shows in the log), but this time the error was something new (I don't remember seeing this one before)

 

ERROR DX11BACKEND: invalid technique pass, line:1516

 

here is the full log:

dcs.20180406-181402.txt

 

BTW, memory commits were about 12GB at time of crash

 

Thanks for any feedback.

Edited April 7, 2018 by prccowboy

[prccowboy]

I was looking thru the Windows logs and it seems that 90% of my crashes are related to transport.dll. Does that imply that the crashes may be related to path finding for the AI?

[msalama]

Does that imply that the crashes may be related to path finding for the AI?

 

A distinct possibility, since I'm seeing lots of transport.dll crashes too. And I only run MIST/CTLD-based pseudodynamic missions with no static AI routing.

[prccowboy]

I'm seeing lots of transport.dll crashes too. And I only run MIST/CTLD-based pseudodynamic missions with no static AI routing.

 

hmm.. maybe that's it. I have been using a lot of mist.groupToRandomPoint in my mission building. I will try a test where I spawn everything stationary.

 

update: A sample size of one isn't a true indicator but by changing my mission scripts to spawning only "stationary" units seems to fix the crash. So, it appears to be a bug related to transport.dll and pathfinding. Bummer, now I need to try rewriting all my missions by building manual paths for the spawned AI

Edited April 8, 2018 by prccowboy

[msalama]

Yup, that's one function I use a lot too and we're getting the same exact crash as well. So I think you nailed it.

[prccowboy]

the crashes definitely seem to be related to path finding and transport.dll. I have had zero crashes since I changed to manually building AI paths (and explicitly avoiding terrain objects along the route) update:

I think I just got lucky on rebuilding that mission. I still have constant crashes no matter what method I use to build AI paths in other missions.

Edited April 12, 2018 by prccowboy

[prccowboy]

Transport.dll crash

 

This is really frustrating me. I still have constant crashes. It appears to always be Transport.dll (at least that is what Windows reports), but so far, I haven't been able to specifically pin down the behavior that causes the crash. However, it *seems* to be related to moving vehicles that are attacked by air (and possibly, dynamically spawned vehicles specifically). Is there a known bug with Transport.dll? it appears that some others have similar problems but I haven't seen a definitive answer on this. :cry:

[toutenglisse]

Hi, the only crash I have is on specific missions and is a "violating access" (or something similar) of transport.dll.

The missions are "infinite CAS/CAP" in Nevada and Caucasus est and west, old missions that I downloaded on user's section.

One time out of 2 (or even more frequently) when I destroy the last ground unit (often a soldier) of a randomly generated vehicule group (tasking from "F10" ingame), the game crash, because of transport.dll.

[prccowboy]

I think this has been resolved => https://forums.eagle.ru/showpost.php?p=3463579&postcount=49