Virtual memory exhausted

[Screet]

Hi,

it seems that Solas had the right idea. I renamed the folder with the js files from OSE and the memory usage suddenly went into the direction I was experiencing without RS/OSE installed.

It still goes up over time, however, it's far less visible and even after several jumps it did not become a problem.

However, there is one insecurity about this: I am missing the big ships from RS/OSE now, namely the Constitutions, Condors and Juggernauts. I've seen other ships from that oxp, but not these big ones...

Furthermore, within that folder is basically missiles and bombs, anti missile system and little else!

Might have to do the tough thing now: enable the script folder again and disable single scripts within...and have a look at what happens.

If anyone feels up to it, please try it!

Screet

[Lestradae]

Does that mean that a single js script could somehow cause all this, Screet?

[Screet]

Does that mean that a single js script could somehow cause all this, Screet?

I've just had a look at that folders contents. My next try is to enable all javascripts, but leave the plist file out which does add a few more patrols with the BIG ships.

Then we will know...my guess: It's the big ships leaking too much memory. There's still a little leakage, but it's not much. Without the scripts, the memory load was as I did see it without RS/OSE installed!

Another observation: The framerate is massively improved by disabling those scripts. I've locked the cards driver to 60fps, but sometimes I can see jumps to way over 200fps before the driver is able to reduce it back to 60.

Screet

[Thargoid]

If it's models then why bother messing with scripts? Javascripts have nothing to do with models and textures. The only way then that snipping out the JS could help would be to stop various ships appearing by breaking them, and so indirectly removing their models and textures.

[Lestradae]

Any idea what could be the issue with the big ships?

EDIT: Could it be the flasher issue? And, will this one be resolved for 1.73?

[Screet]

Any idea what could be the issue with the big ships

OK, I've now re-enabled all JS but renamed this: OSE-XML.plist.disabled

Result: Memory leakage is back, but I also saw big ships this time on my flight...easiest way to crash the game out of memory was to constantly reload my savefile. Didn't need to fly around for this

Screet

[Screet]

Argh.

Back to the beginning I just disabled the scripts folder again and just went reloading my commander...maybe I was just lucky not to have big ships like the constitution around before while flying around. Within the scripts folder there is one script which appears to add more of those, but that they also can appear without it (randomly).

So...all scripts disabled and I was just reloading my save file. Sometimes there was only a small leak of 50MiB, sometimes it was leaking over 500MiB for a simple load of my savefile

Screet

[Thargoid]

There is a version of the constitution that has a pirate role iirc. Have a look in the shipdata.plist from OSE and do a search for "con" or something like that, then check the roles of the ships it finds (look for the roles key).

[Screet]

Hmmm.

Next attempt: Remove the constitution from shipdata, but enable everything else.

Result: There were no extremely big leaks between the loads...it was usually 50MiB to 100MiB leaking per loaded savefile. Still too much for my liking...

Screet

[Lestradae]

Hm, how can there be a save game - related memory leakage depending on if one of the big ships and/or even the Constitution are/is ingame or not?

That puzzles me (not that it takes a lot to do that )



L

[Lestradae]

Addendum: The only things the four big ship classes (Condor, Constitution, Juggernaut & Dredger) have that other ships haven't are, well, 1) bigness and 2) lots and lots of flashers.

Could that mean that one of those two things creates or makes visible those memory leakages?

[Screet]

OK, I'm pretty sure now that it's the models which leak memory!

Without the constitution enabled, the leakage is massively reduced, but still present.

Thus the next logical attempt was to remove OSE completely and just go load/load/load...

Result: Without all those ship models in, the leak was further reduced to 20-50MiB per load usually.

That means that it's not RS/OSE which does cause this problem, but that it is what makes this problem more visible and leads to earlier "out of memory" crashes.

I bet I will now play with OSE in and the constitution removed until the problem can be solved

Screet

[Lestradae]

@Screet:

Could you please attempt again but remove the Constitution(s) and the Condor(s) , too?

Those two ship classes have the most flashers - and if it's the flashers that leak memory, then this should reduce the leakage, too.

[Screet]

@Screet:

Could you please attempt again but remove the Constitution(s) and the Condor(s) , too?

Those two ship classes have the most flashers - and if it's the flashers that leak memory, then this should reduce the leakage, too.

A little bit better. Next attempt was to use the file with those ships, but remove ALL flashers from the shipdata file, which reduced it's size by almost 3500 lines.

Those two versions behave very similar concerning the memory leak.

Then I did remember that I saw some reports about subentities trying to attach themselves to the wrong ship (e.g. after switching ships, loading a different commander or between NPC ships) in the past.

Could it be that subentities (flashers are subentities) leak the most?

Screet

[Lestradae]

Could it be that subentities (flashers are subentities) leak the most?

Wasn't there something about a discovery that flashers would need 30 MBs for some reason unknown?

Now might be the point to get some devs interested to look into this possible subentity/flashers memory leak ... this would also explain why OSE is hit most: It has fifty times more of those in there than anything else.