[railguy]

^ Where I see the missing texture problem is in routes with a lot of scenery, running long trains (which I typically do), with either a lot of loose consists or AI trains. Generally, it is those AI trains or loose consists that will have the missing textures. As noted, if one saves an activity right before a bunch of stuff (like an AI) has to load, then restart the sim from there, the AI will load without having missing textures. That's been my "workaround" for the problem, but it is not one that I like. I would have to suspect that the "memory leak" issue is one that a lot of files get loaded into the sim (say, a bunch of scenery, loose consists, or AI's) and that memory never gets freed up after those files are no longer needed.

Another thing that I've noticed is that certain sound files and the like may "disappear" if one switches camera angles a lot, say, from the front of the train to the back, etc. I suspect the issue may be the same--loading files every time that take space in memory that never gets freed up until one quits the game and restarts it.

[markus_GE]

If Content can only take up 1.6 GB of OpR´s Memory, why does the graph then Show 2 GB as the Maximum?

Wouldn´t it be helpfuly to either shrink the graph´s Y scale or add a line to / at the Magic 1.6 GB, as to make it easier to determine when a save and restart should be performed?

Cheers, Markus

[Csantucci]

Good news here! I tried with the /LARGEADDRESSAWARE switch on my 32bit computer (not forgetting to change the operating system setting), and Open Rails works well at least up to 1.9 GB (that was what I could test with my activity), where I first had problems at 1.6 GB.
Proof is here:

and here:
 OpenRailsLog.zip (3.22K)
Number of downloads: 276

Only problem reported by the logfile is that the sound stream buffers are saturated, but this is only because probably they aren't fully released (maybe something to be investigated by Peter) (and anyhow their upper limit can be increased too). Sounds anyhow still could be heard well.

[James Ross]

markus_GE, on 18 November 2013 - 08:34 AM, said:

If Content can only take up 1.6 GB of OpR´s Memory, why does the graph then Show 2 GB as the Maximum?

The technical limit is 2GB, but in practice you'll struggle to get more than 1.6-1.7GB because of fragmentation and other things interfering in ways you can't predict.

[ATW]

How can one increase the way OR can handle bigger longer trains with more then 1.6 GB, and where is this /LARGEADDRESSAWARE located? My system is a 64bit.

[Csantucci]

I made another run with my test activity (only player train plus loose consists), by running two times from the big starting yard to an intermediate station and returning to the starting yard.
I found out some interesting results:
- memory usage at start: 1370 MB
- memory usage returning at start point: 1830 MB
- memory usage returning second time at start point: > 2 GB (reached 2048 MB and then started showing negative values :dance3: , with bar disappearing, see picture below:

Also at the end of the second run I got no disappearing textures and no errors in the error log, only again some warnings of sound source buffers full.
As I run twice forth and twice back, at least the second time there shouldn't be increase of memory usage. Instead there is a considerable one. So in my opinion there are important amounts of memory that aren't released where they should.
A second thing I found is that not all sounds are correctly released. In fact when returning to the intermediate station for the second time, some sounds of the local loose consists were loaded a second time. I attach here a screenshot from the soundtest interface:

The group of Le724wag.sms entries can be found on top and on bottom of the list, however they are duplicated entries of the same consist.

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. I would prefer that the ORTS developers decide that within the SVN package there is a 2 GB as well as a Largeaddressaware version of OR, so that this is is easily available to everyone and people can select the version they prefer.

[ATW]

Ok thanks for the info.

[James Ross]

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

I would prefer that the ORTS developers decide that within the SVN package there is a 2 GB as well as a Largeaddressaware version of OR, so that this is is easily available to everyone and people can select the version they prefer.

When I get my automatic builds back on-line (from a hard disk failure at the weekend), I should be able to include this easily there and in the weekly experimental builds. Of course, if you're on a 32bit OS, you'll need to reconfigure that if you want to see any difference, but at least on 64bit OSes people can just drop it in to try.

[Csantucci]

That's great news, James!

[gpz]

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

A second thing I found is that not all sounds are correctly released. In fact when returning to the intermediate station for the second time, some sounds of the local loose consists were loaded a second time. I attach here a screenshot from the soundtest interface: (...) The group of Le724wag.sms entries can be found on top and on bottom of the list, however they are duplicated entries of the same consist.

I am wondering if it is really a sound engine problem. Theoretically it is possible, the consists were really added the second time to the scene. (I haven't made any code investigations.)

[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.