OpenBVE
OpenBVE copied to clipboard
leezer3
RouteViewer (64bit) Memory Leak
Description
On the 64bit build of RouteViewer (v1.8.3.2), after reloading any route would have a marginal increase of the RAM Usage. (The more texture the route has, the higher the RAM raises) The RAM will also not be freed when switching to another route
This does not occur on the 32bit version.
Related information
- Operating system: Windows 10 21H2
- Method of control: Keyboard
I worked to the route create about two hours. I am using only the RouteViewer and Blender2.79. But, the memory that was increased from 2.5GB to 10.5GB. And not shown the process list about how many using the memory. So, when I close the RouteViewer, it did not release to the free memory. I doubt that when the re-renderling(F5 key), the temporary memory area is create, but not relase. So, I think that the temporary memory is become to the zombie.
I think maybe that this memory area is not contain the RouteViewer.exe, so it isn't show the process list.
I don't know when this memory-reak happens from that past version.
But, I didn't cognition this happens the 1.7.x.x.
So, I think that this happens maybe from 1.8.0.0.
I reloaded the latest daily build and 1.8.4.2 15 times each. Both leaked memory as below. The problem is that even if you kill the process, the memory will not be released and it will become a zombie. And when you reload more than 5 times, the memory leak suddenly becomes severe. However, no matter how much I search for processes, I cannot find a process that consumes such a large amount of memory. So I have no choice but to reboot the PC. This data is currently being created and will be released later, but it is so large that it takes about a minute to read the route. This route is 500km long, but I don't think it's a matter of distance. I think that it will not occur unless there are 30 or more objects of about 2MB per csv file.
| 20221028 | 1.8.4.2 |
|---|---|
| 1.7GB | 1.7GB |
| 2.23 | 2.28 |
| 2.3 | 2.37 |
| 2.36 | 2.4 |
| 2.35 | 2.4 |
| 2.41 | 2.4 |
| 2.37 | 2.4 |
| 3.17 | 3.6 |
| 4.08 | 4.5 |
| 4.99 | 5.5 |
| 5.92 | 6.4 |
| 6.95 | 7.3 |
| 7.79 | 8.29 |
| 8.8 | 9.25 |
| 9.73GB | 10.2GB |
| killed8.95 | killed9.26 |
I am creating a loading screen's Omiya Station.(This is by 1.8.4.2's viewer) All of OpenBVE's user looks this station's loading screen. (Is it resemble?) This Omiya station uses 32 csv files, 42.4MB. Each csv files about 1-2MB.
Large processes- Try top from a root terminal, instead of the GUI version.
At a guess, I'd try killall mono* to terminate the rouge.
I was not able to stop the process using killall.
I turned it off using the GUI, but I don't think it's affected by mono.
That's why I said zombification.
No real good ideas at the minute I'm afraid.
If it fails to release the memory after killing all Mono processes, that suggests we're triggering a bug somewhere inside Mono, and it isn't 100% our bug.
I've just tried both a copy built by myself and a freshly downloaded copy of the current daily build on the Debian 10 VM. With the latest version of your Tohoku Shinkansen from Sendai, neither of these are leaking memory on Route Viewer here.
Only thing I can find from digging around is this: https://github.com/mono/mono/issues/7655
If you're using the Debian / Ubuntu mono, it might be worth trying the latest from Mono direct.
Recently, I've been motivated to create, and I've finished the work at Omiya Station, so the production pitch is up. If we release it, we can definitely provide it as data that leaks memory, but we are currently using images from multiple authors with CC licenses, so I'm sorry that we can't provide it in advance. It's been a long time since I've been feeling better, so I'd like to make it in the meantime.
Fixed in https://github.com/leezer3/OpenBVE/commit/895d6bc3ad3e5792018f848f3db1fc4aa4812bbc
I reloaded it 10 times and it doesn't seem to leak. i think i can close it. Thanks for the fix!