Oolite Bulletins

Posted: **Mon Mar 30, 2009 12:45 pm**

Oh, I now remember some other observation with that memory problem:

When I did reduce my memory and enabled a disk based page file, Oolite began to use that when growing...that slowed things down while populating systems, but not in flight. That pretty much indicates that a large amount of memory simply was unused and only written to the file, but never reloaded into active memory.

Screet

Posted: **Mon Mar 30, 2009 1:18 pm**

I did allow Vista to use big amounts of disc based space as emergency RAM if it was needed two months ago. Is this what you did too?

Please, let this not be another Vista "unintended feature"

Posted: **Mon Mar 30, 2009 1:59 pm**

Lestradae wrote:
I did allow Vista to use big amounts of disc based space as emergency RAM if it was needed two months ago. Is this what you did too?

First I reduced the RAM from 4 to 2 GiB as Vista 32 cannot address that much RAM anyway. I did do that to test the 4870x2 speed issue I had...but it did not help and Oolite did run out of memory even faster, thus I then did enable the disk based pagefile. Since my primary disc is an SSD and thus silent and the secondary disc is a common drive, I then knew by the access sounds when the system was swapping.

Screet

Posted: **Mon Mar 30, 2009 3:13 pm**

javascripts in OXP .js files may cause memory problems.
to check rename .js files in AddOns and subfolders using Rename Master.
http://www.joejoesoft.com/cms/showpage.php?cid=108

I don't know if this will 'disable' affected ships ..
if it doesn't it should rule .js files in or out as the possible problem.

Posted: **Mon Mar 30, 2009 5:14 pm**

Hi Solas,

Solas wrote:
javascripts in OXP .js files may cause memory problems.
to check rename .js files in AddOns and subfolders using Rename Master.
http://www.joejoesoft.com/cms/showpage.php?cid=108

I don't know if this will 'disable' affected ships ..
if it doesn't it should rule .js files in or out as the possible problem.

Would you mind explaining for a complete noob in those things how exactly javascripts could cause the memory problem on Vista and how renaming scripts might help?

I had a look following the link you provided but didn't manage to get those two informations out of there

L

Posted: **Mon Mar 30, 2009 6:35 pm**

Would you mind explaining for a complete noob in those things how exactly javascripts could cause the memory problem on Vista and how renaming scripts might help?
I had a look following the link you provided but didn't manage to get those two informations out of there

I don't know of another way to temporarily disable Javascripts in OXPs.
the link I provided previously was to a Windows program to rename multiple files.
rename .js files to .js_ + TEST + rename .js_ files to .js

Oolite uses a JS engine from Mozilla.
one potential problem would be an infinite loop ( exit condition never fulfilled )
here's a link relating to possible memory problems / leaks ..
http://www.windowsitlibrary.com/Content/1160/22/2.html
section .. BROWSER SECURITY PROBLEMS WITH JAVASCRIPT

I have not had the problem of memory 'overuse' but then I don't have many OXPs.
The problem may not be within OXP .js files. But it's my best guess.

one other thing .. why do you think the problem is with Vista ?
I've re-read the thread and cannot come to the conclusion that it is Vista specific.

Posted: **Mon Mar 30, 2009 6:40 pm**

If you're going to do this you may as well completely remove the OXP (simplest way is to delete the .oxp out of the folder name).

Randomly removing the javascripts will almost certainly break the OXP anyway (either by removing the generally running worldscripts or by removing the ships scripts).

Hence the OXP ships may not work properly (or may not even appear) if they suddenly lose their relied-upon scripts, and the lack of worldscripts will stop the OXP working in most cases.

Ergo I would most certainly not recommend mucking around in the guts of OXPs like this. Just temporarily remove the whole OXP.

Posted: **Mon Mar 30, 2009 6:43 pm**

Agree with Thargoid here. You will almost certainly see weird behaviour or even crashes if you start randomly removing required scripts, which defeats the purpose of checking against crashes.

Posted: **Mon Mar 30, 2009 7:50 pm**

@ Thargoid
The problem may be within a large number of OXPs installed.
similar results should be had by locating the OXP dirs containing .js files then renaming them temporarily to *.OXP_
I certainly did not suggest randomly doing anything. any changes made are easily reversed.
if temporarily disabling OXPs removes the problem then it points to a problem there.

@ another_commander
you may see non-standard behaviour .. but I doubt you will see crashes by disabling .js scripts within AddOns sub-dirs.
I get the Log file message for a renamed .js file ..
[script.load.notFound]: ***** Could not find a script file named bweed-kestrelfalcon-kestrel.js

I did NOT suggest changing anything outside the AddOns dir.

a better choice for multiple renaming might be Lupas Rename http://www.snapfiles.com/get/lupasrename.html

my suggestion was made to prevent much aggravation in trying to locate the problem.
I cannot see any way that massive memory usage results from textures models etc.

in any case it's worth keeping in mind that .js script files can cause massive memory overuse.

Posted: **Mon Mar 30, 2009 7:54 pm**

Solas wrote:
in any case it's worth keeping in mind that .js script files can cause massive memory overuse.

Please allow me to restate my naive question: How exactly does this happen, if it does?

If this is the reason for the slowdowns and crashes and they don't have anything to do with textures etc., it would be a big step for Oolite to isolate and remove this problem.

L

Posted: **Mon Mar 30, 2009 8:03 pm**

Please allow me to restate my naive question: How exactly does this happen, if it does?

https://bb.oolite.space/viewtopic.php?p= ... ght=#73981

Oolite uses a JS engine from Mozilla.
one potential problem would be an infinite loop ( exit condition never fulfilled )
here's a link relating to possible memory problems / leaks ..
http://www.windowsitlibrary.com/Content/1160/22/2.html
section .. BROWSER SECURITY PROBLEMS WITH JAVASCRIPT

Posted: **Tue Mar 31, 2009 7:41 am**

Solas wrote:
@ Thargoid
The problem may be within a large number of OXPs installed.
similar results should be had by locating the OXP dirs containing .js files then renaming them temporarily to *.OXP_
I certainly did not suggest randomly doing anything. any changes made are easily reversed.
if temporarily disabling OXPs removes the problem then it points to a problem there.

The problem could equally well be in a legacy script.plist, if it's something like ship creation/texture useage or similar which is leaking. Your suggestion of just hacking out js files by rename will lobotomise most OXPs which use them for worldscripting (your Kestrel/Falcon above is a ship-script, which will just mess up the ship in question to varying degrees depending on what the script does).

The temporarily renaming *.oxp to *.oxp_ is the same as mine to remove the .oxp from the end, although I agree yours is easier to automagically undo by the same renaming process. But as you're probably going to want to either take them out one by one or add them back in again one by one, it's something of a moot point.

I'm struggling to find your section in the link that you mean, can you post a more accurate link to the specific page rather than the index one? But a script doing something crazy like adding an infinite number of ships under given circumstances would always fail under those specific circumstances, rather than under say 3 jumps (which would tend to counter that, unless there's counters or somesuch involved).

Posted: **Tue Mar 31, 2009 1:03 pm**

The problem could equally well be in a legacy script.plist, if it's something like ship creation/texture useage or similar which is leaking. Your suggestion of just hacking out js files by rename will lobotomise most OXPs which use them for worldscripting (your Kestrel/Falcon above is a ship-script, which will just mess up the ship in question to varying degrees depending on what the script does).
The temporarily renaming *.oxp to *.oxp_ is the same as mine to remove the .oxp from the end, although I agree yours is easier to automagically undo by the same renaming process. But as you're probably going to want to either take them out one by one or add them back in again one by one, it's something of a moot point.
I'm struggling to find your section in the link that you mean, can you post a more accurate link to the specific page rather than the index one? But a script doing something crazy like adding an infinite number of ships under given circumstances would always fail under those specific circumstances, rather than under say 3 jumps (which would tend to counter that, unless there's counters or somesuch involved).

the problem could be as you say with a .plist file. there most likely are possibilities other than that or a .js file.
temporarily renaming .js files should not damage anything permanently ..
if all are renamed and the problem persists then it's unlikely to be a .js file. at worst you would need to clear the Oolite cache.

I checked the link I posted more than once last night ! I did not encounter the re-direction that happens since.
Googling for 'BROWSER SECURITY PROBLEMS WITH JAVASCRIPT' still points at that link.
Googling again I found this link which contains the same material at .. http://www.devarticles.com/c/a/JavaScri ... ecurity/6/
I've checked this link by clearing my browser cache and reloading.
I hope this helps in some way.

Posted: **Tue Mar 31, 2009 2:00 pm**

I don't think that it is the .js that causes this trouble, because every RandomHits user (e.g.) would have this problem. But testing it doesn't hurt. For a test rig you can simply install the oxps that are using a lot of scripts (and only these oxps).
Random Hits(51), UPS-courier(23), buoyRepair(8), localhero(22), militaryFiasco(5), Pods(12) >100 scripts

On my machine I already have >90 js-scripts running and no ladder pattern.

@L: Can you try it without your OSE?

Posted: **Tue Mar 31, 2009 4:36 pm**

Svengali wrote:
@L: Can you try it without your OSE?

As I said, the problem exists primarily with RS/OSE installed and many of it's ships flying around! The memory does drop back when a system isn't that full, but the more ships, the earlier the memory problem becomes visible.

I really expect it to be the models...maybe I should just rename the folder containing the js scripts and have a look at what happens...

Screet

Oolite Bulletins

Virtual memory exhausted

..

Re: ..

...

?