Virtual memory exhausted
Moderators: winston, another_commander
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
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
Re: ..
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.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?
Screet
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.
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.
- Lestradae
- ---- E L I T E ----
- Posts: 3095
- Joined: Tue Apr 17, 2007 10:30 pm
- Location: Vienna, Austria
...
Hi Solas,
I had a look following the link you provided but didn't manage to get those two informations out of there
L
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?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.
I had a look following the link you provided but didn't manage to get those two informations out of there
L
I don't know of another way to temporarily disable Javascripts in OXPs.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
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.
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.
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.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
-
- Quite Grand Sub-Admiral
- Posts: 6682
- Joined: Wed Feb 28, 2007 7:54 am
@ 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.
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.
- Lestradae
- ---- E L I T E ----
- Posts: 3095
- Joined: Tue Apr 17, 2007 10:30 pm
- Location: Vienna, Austria
?
Please allow me to restate my naive question: How exactly does this happen, if it does?Solas wrote:in any case it's worth keeping in mind that .js script files can cause massive memory overuse.
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
https://bb.oolite.space/viewtopic.php?p= ... ght=#73981Please allow me to restate my naive question: How exactly does this happen, if it does?
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
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).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 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).
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
the problem could be as you say with a .plist file. there most likely are possibilities other than that or a .js file.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).
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.
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?
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?
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.Svengali wrote:@L: Can you try it without your OSE?
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