All of a sudden - Route viewer and Object viewer not working

Well, it is happening daily on my end... wondering whether it could be a crosslinked file on HD, or just having WMP tuned on!
But I can confirm Jeff's solution, everything's fine after a reboot... WEIRD.

I did mention this just before the closure, but we have quite a major memory leak somewhere either in OpenBVE or in the .Net framework itself.
Michelle didn't want to believe me, but it's there.

Easy enough to reproduce, find an object that eats a significant amount of memory, make a small change and reload. Rinse and repeat a few times, and the memory usage goes through the roof. (My WIP 81xx external eats another 15mb every time I reload a change)
Large routes and objects will suffer from this, and eventually you'll run out of available memory, hence the issues.

Logging out and back in again seems to purge the memory in use, but I can't really give a better solution at the minute.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

According to Michelles answer back then it is an issue with .NET's garbage collector.

I'd say it's a .net issue as well in as everything I've read says you should leave the .net garbage collector to do it's job. But it is slightly strange that only logging out gets the memory back, as exiting the viewer should release memory that it used, I thought this was done by windows but may have got that wrong.

Quork wrote:According to Michelles answer back then it is an issue with .NET's garbage collector.

Take it from me, it's not (I never got the chance to argue this point before everything)
The garbage collector is not failsafe, or for that matter particularly smart. See this MS article on .Net memory leaks:
http://msdn.microsoft.com/en-us/magazine/cc163491.aspx
I have a strong suspicion we're leaking when we load the textures into memory. I'm investigating, but I can't do much more than pinpoint the source of this leak, as while I understand what's going on, I've never tried anything this advanced in terms of debugging.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

and theres me thinking it was antequated laptop giving me the run around, I will be interested in the outcome of this thread..oh yeah, my problem...after repeated use of RV, suddenly laptop runs out of system memory, a quick reboot of RV and its all fine again..for a while...

leezer3 wrote:
Take it from me, it's not (I never got the chance to argue this point before everything)
The garbage collector is not failsafe, or for that matter particularly smart. See this MS article on .Net memory leaks:
http://msdn.microsoft.com/en-us/magazine/cc163491.aspx
I have a strong suspicion we're leaking when we load the textures into memory. I'm investigating, but I can't do much more than pinpoint the source of this leak, as while I understand what's going on, I've never tried anything this advanced in terms of debugging.

I read that it's an interesting article, and did a little test based on the tests recommended in it. The results of which do seam to indicate an increase in the number of private bytes used and an increase in the size of the heap with all but 1 of the reloads I did, I guess the garbage collector did something around that time. Also interestingly when I completely closed the object but left object viewer running the figures did drop but not by much and not to their initial values after starting object viewer in the first place.

It's certainly worthy of a little further investigation.

I said that this needed a little more investigation which, is what I've done after some profiling ObjectViewer and trying to debug a memory dump of the application. I think I'm begining to get an idea of what's going on / wrong here.
Firstly looking at the profile I found that after reloading an object 5 times in reasonably quick succession. Their were 5 blocks of System.Byte[] and OpenBve.Font.Character[] objects on the large object heap, grouped together ie. 1 Byte[] and 1 character[] of the same age. Also of interest was the size of the gen 2 heap compared to the size of gen 0 and gen 1 heaps, it was the largest so objects are getting promoted to gen 2 quickly.
So I did the same and took a memory dump of ObjectViewer, to see what was keeping the Byte[] and Character[]s alive. After looking for these objects I then looked for the root that was preventing them from being garbage collected expecting to be able to quickly trace the source of the leak. The result was interesting to say the least nothing was preventing these from being collected they had no root. I then looked at the gen 2 heap in more detail looking for objects with lots on instances, then checked to see what roots were keeping them alive. I found that often only about a quarter had roots and the rest could be collected.
I also noted that several objects had their finalizers run, promoting them to gen1 at the very least.
So I would say the root cause is that objects are getting in to gen 2 and then dying very soon after noticeable on the large object heap. This means they will be collected freeing the memory at the next gen2 collection, however this will not happen until there isn't enough space on the heap for the needed allocation and space cannot be gained though gen 0 and gen 1 collects. As a gen2 collect has a big performance hit compared to gen 0 and gen1 you may notice a slow down whilst this happens. The more worrying thing is that the large object heap could become fragmented over time as the collector doesn't compact the objects when it runs.

What to do? A short term fix would be to perhaps force a garbage collection before a reload. A longer term fix would be to try to prevent objects being kept for so long in the first place.

You mean putting something like a destructor in the code? I think it is called this way...

I've heard of that it's a bad idea to call GC.Collect...
Perhaps an idea is to force starting a new process of the Object Viewer, then all those resources will be freed as soon as possible.

Yes it's generally not good idea to call GC.Collect best to leave it to it. However when lots of objects are going to dye all at the same time as in a reload or loading a new object I think it could be justified to give the GC a helping hand.
Alvin you're right that it would be better to find a longer term solution to the problem, but as a short term fix it does seam to work.

Derryck, destructors don't exist in C# they're called finalizers and shouldn't be used unless their is good reason to do so.

LabRatAndy wrote:Derryck, destructors don't exist in C# they're called finalizers and shouldn't be used unless their is good reason to do so.

Like GDI+ objects like Brushes and Pens needs to be disposed properly as GDI+ isn't managed and can cause memory leaks.
Usually in managed code if an object is not referenced anymore, the GC will collect them automatically.

LabRatAndy wrote:Derryck, destructors don't exist in C# they're called finalizers and shouldn't be used unless their is good reason to do so.

I think there IS a "constructor" and a "destructor" (though possibly called differently), which is the opposite.

Yes Derryck, a constructor initialises the object you've just instanced a destructor cleans up after the object as it is deleted from memory.

LabRatAndy wrote:Yes it's generally not good idea to call GC.Collect best to leave it to it. However when lots of objects are going to dye all at the same time as in a reload or loading a new object I think it could be justified to give the GC a helping hand.
Alvin you're right that it would be better to find a longer term solution to the problem, but as a short term fix it does seam to work.

Derryck, destructors don't exist in C# they're called finalizers and shouldn't be used unless their is good reason to do so.

I'd say force the garbage collection somewhere about every five reloads or so as a temporary measure. This would allow for reasonable memory performance whilst not giving the full hit of a garbage collection run every time you tweak something.
From my own reading into this, I'd say it's something somewhere in the OpenGL bindings preventing them being collected, and my prime suspect is still the textures. The Object is a root GC object, and there's nothing about it that should stop it being collected fundamentally. Supporting this to some extent, is that if you compile with the OpenTK compatibility libraries, you'll see marginally decreased memory usage (Noticable on stuff like heavy animated usage/ custom normals), but sadly it still leaks here.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

You may be right about the openGL bindings as they do seam to be the source of a lot of the memory allocations made.

Coming back to this one, I had a load of .Net updates pushed via Windows update today, which appear to have solved this with no outside intervention. Memory usage is now hovering around a nice constant 60mb for the WIP 81xx as opposed to eating 15mb every time I reload.

Would be nice if someone else could verify this

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Could you provide a link to that update, or do you go with Windows update system?

I've just tested memory usage on my Win 7 installation, which is up to date. I opened the Schlierenwagen I'm building, memory usage was around 42MB. When I reloaded memory usage went up for a second and back again to around 42 MB, so everything seems to be fine here.

leezer3 wrote:Coming back to this one, I had a load of .Net updates pushed via Windows update today, which appear to have solved this with no outside intervention. Memory usage is now hovering around a nice constant 60mb for the WIP 81xx as opposed to eating 15mb every time I reload.

Would be nice if someone else could verify this

Cheers

Chris Lees

http://www.bvecornwall.co.uk

What is the last time you ever ran Windows Update?

Not sure I follow. Normally run Windows Update about once a week, but this was a relatively fresh install, so some updates may have been delayed a little.
Definitely a recent development though.

Cheers

Chris Lees
http://www.bvecornwall.co.uk