[jonas]

Hi,

When trying to drive through my route of about 300 km from start to finish in OR, a memory error occurs after about 2/3 of the way.

According to the OpenRailsLog.txt there are first while trying to load one or the other texture a few warnings because of insufficient memory and finally because of missing memory an error with program abort occurs.

I hope we are not with OR in the meantime at the same place, at which MSTS was criticized mainly?! It is a known bug in MSTS that the memory is not released accurately after leaving world tiles. This leads to the fact that driving on longer routes with a larger amount of shapes and textures overloads the MSTS. Often, when loading the next world tile, several messages appear in MSTS that SMS objects can no longer be loaded. By the way, the MSTS then usually does not crash, but simply leaves the next to load world tiles empty.

Two facts that were alarming me:
• the MSTS manages the same 2/3 of the way of the same route easily, while OR crashes.
• while riding the 2/3 of the route in OR according to the task manager the memory of the RunActivity.exe rise continuously from 230.000 kB up to over 587.000 kB! Then the crash occures.

Regards
Jonas

 OpenRailsLog_Memory.txt (43.63K)
Number of downloads: 255

[Csantucci]

Hi Jonas,
with 3 GB RAM and a 32-bit operating system you can expect behaviours like this one; you have also ConditionalLoadOfDayOrNightTextures set to false: try setting that option to true.

[jonas]

 engmod, on 01 November 2021 - 02:42 PM, said:

...

Given that MSTS and OR crash at the same place, I suspect you have a shape that is calling for a LARGE amount of memory.
...

That's just it, MSTS doesn't crash on the route while OR does. And OR used to not crash either in older versions, let's say about 1 year ago, and was able to go through the route without an error. I've nothing changed in the route since then.

It is certainly true that I'm not using the best machine. But that's not really the point I'm trying to make.

The point is:

Shouldn't it be better that the shapes and textures of a tile that a train has left far behind should better be cleared in memory too?

MSTS has been criticized early in the community for this no deleting in memory and I think that OR should not "copy" this deficiency (without being able to improve it myself).

The memory fills proportionally to each kilometer driven, without ever seeing a memory release in the task manager.

I wonder how it would work with such huge distances as the Czech "Trat' 321" (1935 km!), even with a much better PC than mine.

I may not have found the manual part for it. What are actually the minimum PC requirements officially recommended by OR at the moment?

[engmod]

Hi Jonas,

We had another user with crashes when the video memory was 0.3gB.

Your machine is getting very close at:-
Video = NVIDIA GeForce 9700M GT (0,5 GB RAM) (nvlddmkm 21.21.13.4201)

It may be the change in the video processing that is troubling you as well.

You may have to stay with 1.3 if you want to.

[cjakeman]

 jonas, on 01 November 2021 - 04:08 PM, said:

The memory fills proportionally to each kilometer driven, without ever seeing a memory release in the task manager.

What Derek writes is true, but I think Jonas has a very valid point. If the memory is consumed and never released then eventually it will run out. That's true however much you have installed and however modern your PC.

@Jonas - Would you raise a bug report with enough information for someone to look into this? Thanks.

[engmod]

Hi Chris,

I think the out of memory error is coming from the video card not main memory, hence my post.

[jonas]

 engmod, on 02 November 2021 - 12:11 PM, said:

... I think the out of memory error is coming from the video card not main memory, hence my post.

I think if it would be the video card, then the error should have appeared also in the 1.3 version on my old fashioned laptop.

It concerns me however around this main memory here:


---
Thanks for the advices to Carlo and Derek! I turned on the options "Load day/night textures only when needed", "Large address aware binaries" and tried saving the activity. Unfortunately, turning on the both options did nothing. The saving followed by closing and then reloading the activity was successful and the error did not appear, so I was able to drive through to the end of the route.
Honestly, as I had expected it to be. The memory is nowhere near as full after reloading as it was when I saved the activity half a way.
But I think we should now detach ourselves from the concrete solution possibilities for such old PCs like my laptop and better concentrate on the basic problem lurking behind it (even if it is then no longer quite a "may be it's a bug"-topic probably).
---

 cjakeman, on 02 November 2021 - 11:06 AM, said:

...but I think Jonas has a very valid point. If the memory is consumed and never released then eventually it will run out. That's true however much you have installed and however modern your PC. ...

Thanks Chris for highlighting this point again.

When driving with ORs previous version 1.3 you see a different, I would say "healthier" memory management behavior. When starting the activity of my route, the memory is indeed significantly filled (over 500,000 K) from the beginning, but while driving to the end of the route I see again and again jumps down, by up to 100,000 K. So the memory is regularly released again after leaving world-tiles. I would say the "garbage collection" is working well.

With version 1.4, on the other hand, it is as described above: The memory fills proportionally to each kilometer driven, without ever seeing a memory release.
When I start the activity in 1.4, there is significantly less memory used at the beginning (250.000 K) than in version 1.3, but after start driving, the memory usage increases more and more - and knows only one direction: increasing!

So I quote myself here again from post #1: "I hope we are not with OR in the meantime at the same place, at which MSTS was criticized mainly?! It is a known bug in MSTS that the memory is not released accurately after leaving world tiles."

I can only agree again with Chris here: It is (will) become a problem that will affect other PCs in the future, no matter how old or modern they are! At least when it comes to driving long routes, I'm afraid.

[jonas]

Hopefully a last modest attempt to get to the heart of the matter. I suggest, of cause only for the one who has the time, to go into "my" basic problem of the constantly filling memory.
I don't understand why more and more memory has to be used when driving the always same(!) route with different OR versions. Of course, new features in OR are associated with the use of more memory, but does this explain the permanent occupation of memory with every driven kilometer of a route? If so, I would like to understand it. And so far I haven't hear any explanation, if I'm right with this impression.

I would be interested to know if even on modern PCs the memory occupation with each kilometer driven on a route moves permanently in only one direction: increasing.
Perhaps there is someone, preferably with a modern PC, who is willing to share the experience here and confirm or refute my observation.

Because if it is that way (and only if) I consider it as an serious problem for OR.

[Csantucci]

I did some checks in the past about memory allocation, as neither I have a very performing computer (4 GB RAM + 0,5 GB graphic RAM), and suffered from such problems.
Here I write what I understood; there might be some sentences that real IT expert would partly not agree (with reason), because I'm not an IT expert.
OR does not free immediately the memory occupied by objects that are no more needed (e.g. shapes and textures). I understand that memory release is automatically done by the .Net Optimization Engine, as explained here https://www.geeksfor...-net-framework/ . The problem is that the moments where these automatic garbage collections are unpredictable, at least for me, and change also from run to run of the same activity, and I experienced that this can occur also more than 10 minutes that an object has been freed by OR (but sooner or later it occurs - maybe in the meantime a low spec computer has already crashed). So the graph of the used memory has a bit of a sawtooth aspect.
To make things more complicated, there is managed memory and unmanaged memory.
a garbage collection may also be explicitly requested by the code, with the method GC.Collect(), however I believe to remember that someone expert here affirmed that it is not a suggested approach.
In ORNYMG I have inserted an option that frees the memory occupied by e.g. shapes and textures as soon as they are no more needed. Unfortunately it has some drawbacks, so I never moved it into the official OR. However I personally use it when I get stuck with heavy routes/activities.
Something about garbage collection may be read in this recently updated contribution https://www.geeksfor...-net-framework/ .

In my opinion it could be tried to insert in the code a call to GC.Collect() every e.g. 5 minutes, however I'm not sure that this would fully solve the problem, because there is this thing about managed and unmanaged memory which I don't understand. I often see in the debug HUD a low amount of managed memory, but at the same time a high amount of used memory, which includes much memory occupied by no more objects.

I hope that what I have writtend does not only generate confusion.

[jonas]

A good answer in my eyes. Did not confuse me, but made clear the vagaries of the problem. Thank you Carlo for taking the time to be that detailed.

I must admit that only now after reading your last post I tested the whole thing with ORNYMG (Rev 108) too. The error does not occur and I was able to complete the activity, which runs about two thirds of the route through, without any problems. So far I only get the crash in the activity with the current OR U2021.11.01-0706 and the stable 1.4.

The memory also fills continuously with the ORNYMG.

However, when I drive the entire route of 300 km with ORNYMG 108, I get the crash again after about 3/4 way of the route.
I know, my laptop is too old.
 OpenRailsLog.txt (98.76K)
Number of downloads: 227

Maybe a garbage collection every 5 minutes, as you suggested Carlo, would actually help, as a precaution even on more modern machines.

Best regards
jonas