[gpz]

As I see, TrainCar doesn't implement IDisposable, so it is sure they stay in memory once loaded. There is an IsPartOfActiveTrain property of them, which controls unloading of bundled sound. AI trains members use it, but I'm not sure what happens with loose consists. I think TrainCars of loose consists will never be unloaded from memory.

[Csantucci]

Thank you for the analysis, Peter. This in fact coincides with my qualitative tests. Some time ago I made another memory usage test running a train back and forth, but without loose consists, and in that case memory remained constant when returning to the starting point.
In the case above and in similar cases I had the qualitative impression that memory usage growing from run to run was at least partially due to re-loading of consists.
So solving this problem would probably not only reduce occupancy of sound source buffers, but also reduce the general problem of unjustified increases of OR memory usage.

[James Ross]

gpz, on 18 November 2013 - 10:35 PM, said:

As I see, TrainCar doesn't implement IDisposable, so it is sure they stay in memory once loaded.

Where did you pick this up from? It is categorically untrue that classes need to implement IDisposable to be cleaned up/removed from memory.

[Csantucci]

I have rerun the activity depicted in the above screenshots, but this time without loose consists. I have again made twice the run from big station to intermediate station and back. These are the tree memory usage values at application start, at first return to start station, and at second return to start station: 1028 MB, 1123 MB, 1131 MB. The increase is justified, as James explained somewhere else. Important thing is that second and third value are practically the same, so no memory leak without loose consists.
The tests of my preceding posts however show that there is memory leak with the loose consists. So I'm not able to enter into Peter and James' discussion, but there is something about memory release of loose consists that does not work; this is evidenced both by the double memory increase I had in such previous tests and by the double entries in the active sound source list.

By the way loose consists are trains too, I guess of type static. Do they have to be explicitly disposed or James' rule applies?

[James Ross]

Csantucci, on 19 November 2013 - 02:14 AM, said:

By the way loose consists are trains too, I guess of type static. Do they have to be explicitly disposed or James' rule applies?

An object is collected (disposed) automatically once nothing else refers to it. So although we don't need to explicitly dispose them, we do need to make sure they are removed from whatever is holding on to them.

There are two main parts to a train: the simulation part, and the viewer part. The simulation part is not disposed unless it is an AI train and the AI is completed (and is removed), or that should be the case. If we disposed the simulation part, you'd no longer know where the train was! But this part should not use much memory at all. The viewer part is created on-demand, when a train is close enough to need to be visible, and should be disposed of once the train is far enough away to no longer be visible. There is also a cab part, which should work similarly to the viewer part.

It is quite possible we're not disconnecting the viewer or cab parts as we should; although I've carefully checked other parts of the viewer (mostly around terrain/scenery) to ensure we release things in due time, I have not done this with the train viewer parts. It's on my list though.

[gpz]

I would suggest Carlo to make a test by removing all the references to any sms files from eng files, to prove or exclude that this is because of the sound. If memory leak is gone, then it is a sound issue, if it is still there, then not.

(Just to make it clear: I am not a pro, just a "wannabe" programmer, so despite of Carlo's big words, what I say is not an analysis, just a thought of a (as we say here) sane peasant brain. So forgive me if I say untrue things sometimes, I believe the pros, no need for a decapitation.)

[Csantucci]

Hm Peter,
I have to modify about 80 trainset files... I will see. I don't think it can be - only - a sound problem. In my test with loose consists memory usage increased also from first to second return to the start station. And in both cases the sound source buffer was full. So it seems that some other thing increased.

James,
I'm sure you'll find something interesting in your checks about viewer parts of trains (and I suspect not only of static trains)!

[markus_GE]

Csantucci, on 18 November 2013 - 12:49 PM, said:

Referring to the request of ATW, it is not completely straightforward to generate and run such a release of OR, because it requires an extended development environment (Visual C# Express is not enough, or at least mine was not enough), and the change to the OS settings depends from the OS.

Isn´t there also a Utility out there that will perform this Switch on any existing program? I´ll dig in the swamps of my HD´Ds' Folder structures as I seem to recall I downloaded something like this for MSTS some time ago...

Cheers, Markus

[railguy]

I definitely think that loose consists may be one of the memory culprits. When I run activities with a lot of loose consists, I'm more prone to run into the problem with missing textures. However, it may not only be the "failure to unload" of loose consist files that causes the memory leak--it may be the way the program actually loads the file. I don't have a log on this, but here is why I think that might be the case. I run one activity that I built for Horseshoe Curve where I have about 3 AI trains, but very few loose consists. The player train is a 100 car coal train with rear helpers. The player train meets an AI train at Cresson--the AI train being an intermodal having about 70 cars. On the siding is one loose consist with one locomotive. About 2/3's of the time, the AI train will have missing textures if the loose consist locomotive is on the siding. I re-did the activity without it and re-ran the activity a couple of times--no missing textures. After reading this discussion, it got me wondering if the program somehow multiplies the file size of a loose consist for some unknown reason. My other completely off-the-wall speculation is that maybe the full-throttle locomotive loose consist issue might also be related to how the program treats loose consists. Maybe just a coincidence, but maybe not?

[gpz]

The full-throttle issue is a different thing, that is just a value somewhere set to 1 instead of 0.

[disc]

gpz, on 19 November 2013 - 03:55 AM, said:

I would suggest Carlo to make a test by removing all the references to any sms files from eng files, to prove or exclude that this is because of the sound. If memory leak is gone, then it is a sound issue, if it is still there, then not.

(Just to make it clear: I am not a pro, just a "wannabe" programmer, so despite of Carlo's big words, what I say is not an analysis, just a thought of a (as we say here) sane peasant brain. So forgive me if I say untrue things sometimes, I believe the pros, no need for a decapitation.)

How about bulk renaming the sms files, so OR can't find them and maybe it won't crash because of this.

[Csantucci]

disc, on 20 November 2013 - 06:31 AM, said:

How about bulk renaming the sms files, so OR can't find them and maybe it won't crash because of this.

OK, this seems to be a feasible idea. When I have time I'll try that. I will also use train store to reduce the number of the affected files, just in case.

[Csantucci]

I've done the test. All "sound" keywords in .eng and .wag files were replaced with "pipound" (ORTS didn't care about this...); ttype.dat was emptied, and all .ws files were moved elsewhere. The sound test interface showed only ingame.sms and clear.sms remaining.
I again run twice back and forth from the big station to the intermediate station. Result: Peter can sleep quietly this night ;) .
Memory usage at game start: 1375; memory usage at first return to big station: 1927; memory usage at second return to big station: -1789 (in reality 2307). With sounds enabled these values were: 1370, 1830 (1891 in another run), -1794 (in reality 2302).
So:
1) the problem remains 100% there even without sound
2) (less important) most likely OpenAl sound source buffers eat memory somewhere not monitored by James' bar, at least in a /LARGEADDRESSAWARE .exe (I can't believe that sound occupancy is equal to 0).

[JTang]

I am using ANTS to profile our memories. So far found one problem related to level crossing: it does not dispose sound source correctly. Have committed the fix.

[Csantucci]

Hi Jijun,
your further fix about removal of leaks on TrainCarViewer (rel. 1869) was a great job! I made again the test with the double run back and forth from the big station to the intermediate station.
These were the memory occupancies before your change at game start, on first return to big station, on second return to big station:
1370 MB, 1830 MB, 2302 MB.
With your release 1869 (pls. notice that you haven't changed Revision.txt, that continues showing 1867; I've made the test with a rebuilt version with the /LARGEADDRESSAWARE switch) the memory occupancies are: 1366 MB, 1406 MB, 1407 MB (see picture). In the picture it can be seen from the bar that some seconds before the screenshot memory occupancy was about 100 MB higher; in the first run this was even more (a bit above the critical 1,7 GB threshold), but important thing is that then the value decreased to the original value.

So there are no more leaks! And also no more topping in amount of used Sound source buffers, and no more duplicate sound sources!
I didn't do an accurate test about drawbacks on sound playing, but did not notice strange things as first impression.
This modification together with the public availability of a /LARGEADDRESSAWARE version will reduce to zero for some time complaints about ORTS low memory problems (I hope...).

For testing purposes I attach here the /LARGEADDRESSAWARE version of Runactivity.exe related to release 1870. This version can be replaced and run directly on 64-bit Windows systems. On 32-bit Windows system (that MUST have at least 4 GB RAM) an explanation of what has to be done can be found here: http://usa.autodesk....&linkID=9240617
This should be tried only by expert users of computer. There is no liability from my side if someone destroys his operating system or any other hardware or software item.

 RunActivity_LAA_v1873.zip (562.22K)
Number of downloads: 251