Oolite Bulletins

Posted: **Mon Feb 27, 2012 8:24 am**

Solonar wrote:
Yes I have seen these log errors but it does not negatively impact the Oolite performance as far as I can see. I changed the role to trader(0.1) so that their appearance are still semi-rare.

Those log warnings are harmless by themselves, just a reminder that the ship has wrong dimensions for its role.

When you indeed get improvement because of changing the roles, than it is not because that role crashes oolite, but one of the ships is responsible for it. Changing it to trader, just makes the chance of appearing smaller and thus the change of such a crash. Better would be to identify the ship in question and remove that.

I remember from my old Mac that the hammerhead often crashed my Oolite when it was added to the universe. At that time thargoid provided me with a much smaller texture file for the ship. Not as nice, but stopped crashing. I also remember that the Aurora could crash my previous Mac on adding the ship to the system. And I assume there are more ships with big texture files that could do that.

Posted: **Mon Feb 27, 2012 9:56 pm**

Capt. Murphy wrote:
... a debug build of 1.76 revealed that it's a GPU driver file that's involved with this crash. So the conclusion I draw is that a lot of unreproducible crashes are Graphic Driver related, rather than Oolite related as such.

Are there known solutions to this CTD problem should what you indicate cause it?

Posted: **Mon Feb 27, 2012 10:36 pm**

OK, now I caught the Windows message when the CTD happened:

Microsoft Visual C++ Runtime Library

This application has requested the Runtime to terminate in an unusual way.
Please contact the application's support team for more information.

The stderr had this to say:

Virtual memory exhausted
WARNING thread 25B486E8 terminated without calling +exit!

Last five lines of my log:

23:32:00.478 [CargoTypeExtension]: Set price for CTE_CTD_18 to 48 with 0 TC available
23:32:00.478 [CargoTypeExtension]: Set price for CTE_CTD_19 to 24 with 0 TC available
23:32:00.479 [CargoTypeExtension]: Set price for CTE_CTD_20 to 48 with 0 TC available
23:32:00.640 [testscript.spawn]: Generated 1 nest for testing purposes.
23:32:01.697 [bigShips_populator]: 3 big trader(s) added to the Dimadi system.

Is that some helpful info to you people in the know or just a glorified "run out of memory somewhere" message again?

Posted: **Tue Feb 28, 2012 5:22 am**

Lestradae wrote:
Capt. Murphy wrote:
... a debug build of 1.76 revealed that it's a GPU driver file that's involved with this crash. So the conclusion I draw is that a lot of unreproducible crashes are Graphic Driver related, rather than Oolite related as such.
Are there known solutions to this CTD problem should what you indicate cause it?

Hassle Intel to bug fix their drivers.....

It's not just Oolite - the Intel forums have lots of people complaining about commercial OpenGL titles not working as they should.

Posted: **Tue Feb 28, 2012 6:55 am**

Lestradae wrote:
OK, now I caught the Windows message when the CTD happened:
Microsoft Visual C++ Runtime Library

This application has requested the Runtime to terminate in an unusual way.
Please contact the application's support team for more information.
The stderr had this to say:
Virtual memory exhausted
WARNING thread 25B486E8 terminated without calling +exit!
Last five lines of my log:
23:32:00.478 [CargoTypeExtension]: Set price for CTE_CTD_18 to 48 with 0 TC available
23:32:00.478 [CargoTypeExtension]: Set price for CTE_CTD_19 to 24 with 0 TC available
23:32:00.479 [CargoTypeExtension]: Set price for CTE_CTD_20 to 48 with 0 TC available
23:32:00.640 [testscript.spawn]: Generated 1 nest for testing purposes.
23:32:01.697 [bigShips_populator]: 3 big trader(s) added to the Dimadi system.
Is that some helpful info to you people in the know or just a glorified "run out of memory somewhere" message again?

This is the typical situation of memory depletion.

Posted: **Tue Feb 28, 2012 8:39 am**

The thing is, how is virtual memory depletion even possible with virtual memory set to a terabyte?

Posted: **Tue Feb 28, 2012 8:42 am**

You can set your virtual memory to as many terabytes as you want, but you have to remember that Oolite is built as a 32-bit application. This means that the maximum memory size visible for this and any other 32-bit app on Windows is 2GB or 4GB, depending on whether IMAGE_FILE_LARGE_ADDRESS_AWARE is cleared or not. See this for more information: http://msdn.microsoft.com/en-us/library ... s.85).aspx

You are basically hitting the 32-bit memory access limit, not your computer's physical memory capacity limit.

Edit: Fixed link. phpbb's automatic link recognition failed earlier.

Posted: **Tue Feb 28, 2012 8:47 am**

Your link doesn't work for me

OK, so no luck with the virtual memory extension. And I guess attempts at creating a 64bit version for Windows are really complicated? (Nevermind, I know the answer to that one

)

Posted: **Tue Feb 28, 2012 8:55 am**

Lestradae wrote:
Your link doesn't work for me

OK, so no luck with the virtual memory extension. And I guess attempts at creating a 64bit version for Windows are really complicated? (Nevermind, I know the answer to that one )

Try copying the entire link and pasting it on the browser's address bar. It ~~should work~~ now works.

And no, we do not have ability at the moment to make 64-bit builds of the game for Windows. Anyone interested to do this, feel free to apply.

Posted: **Wed Feb 29, 2012 8:33 pm**

Something new happened - pagroove suggested I post this here so that the code wizards can make head or tail of it.

Crash report now ended like this:

14:23:48.878 [ship.missileLaunch.invalidPosition]: ***** ERROR: The missile_launch_position defines a position (0, 0, 0) behind the <ShipEntity 0x4155e788>{"Orisis class Ferry" position: (-4710.33, 2626.08, 278452) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}. In future versions such missiles may explode on launch because they have to travel through the ship.
14:23:51.755 [ship.missileLaunch.invalidPosition]: ***** ERROR: The missile_launch_position defines a position (0, 0, 0) behind the <ShipEntity 0x4155e788>{"Orisis class Ferry" position: (-4688.86, 2596.82, 278851) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}. In future versions such missiles may explode on launch because they have to travel through the ship.
14:23:54.115 [ship.missileLaunch.invalidPosition]: ***** ERROR: The missile_launch_position defines a position (0, 0, 0) behind the <ShipEntity 0x4155e788>{"Orisis class Ferry" position: (-4670.76, 2572.17, 279186) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}. In future versions such missiles may explode on launch because they have to travel through the ship.
14:23:55.916 [ship.missileLaunch.invalidPosition]: ***** ERROR: The missile_launch_position defines a position (0, 0, 0) behind the <ShipEntity 0x4155e788>{"Orisis class Ferry" position: (-4656.41, 2552.62, 279452) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}. In future versions such missiles may explode on launch because they have to travel through the ship.

Thing is, the Orisis according to pagroove is not supposed to have missiles at all.

I did not see the ship, the game crashed when exiting a station (the first and only time it did not crash at exiting hyperspace since I play 1.76).

Edit: Hm, also found this at a later crash:

22:15:39.972 [general.error.allocationFailure]: Failed to allocate space (16744464 bytes) for texture ../AddOns/Orisisv1.3.oxp/Textures/adck_orisis_n.png

... which is weird, as the texture in question has around 2.7MB and not 16.7MB?

Posted: **Wed Feb 29, 2012 10:32 pm**

Lestradae wrote:
Edit: Hm, also found this at a later crash:

22:15:39.972 [general.error.allocationFailure]: Failed to allocate space (16744464 bytes) for texture ../AddOns/Orisisv1.3.oxp/Textures/adck_orisis_n.png
... which is weird, as the texture in question has around 2.7MB and not 16.7MB?

No it is really 16.7MB. 2.7MB is the compressed version, but in memory it is always uncompressed. When I do a ’save as uncompressed tiff’, it becomes 16.7 MB according to my picture viewer.

And seeing the Orisis model again, I remember it was this particular ship that regularly crashed my other computer that runs on OSX 10.5 (32 bit). Currently I am using OSX 10.6 and there I do have 64 bit.

Posted: **Wed Feb 29, 2012 11:25 pm**

Eric Walch wrote:
Lestradae wrote:
Edit: Hm, also found this at a later crash:

22:15:39.972 [general.error.allocationFailure]: Failed to allocate space (16744464 bytes) for texture ../AddOns/Orisisv1.3.oxp/Textures/adck_orisis_n.png
... which is weird, as the texture in question has around 2.7MB and not 16.7MB?
No it is really 16.7MB. 2.7MB is the compressed version, but in memory it is always uncompressed. When I do a ’save as uncompressed tiff’, it becomes 16.7 MB according to my picture viewer.

Obviously it's a 2048 x 2048 texture, which is quite big compared to other textures in Oolite. I had problems with the original Superhub texture which was 2048 x 2048 as well, until I reduced it to 1024 x 1024. And as Eric already said, the texture file size is irrelevant. It gets put into the graphics memory as a bitmap in 32bit colour. 32 bits are 4 bytes. 4 bytes x 2048 x 2048 = 16744464 bytes total memory need. And of course it's only one of several textures needed by the ship.

There are light versions (1024 x 1024) of some of the textures sitting conveniently in a sub-folder. There are even a 'very light' versions (512 x 512) sitting conveniently in that sub-folder. However, there are no light versions of all textures involved.

On a side note, the texture (and all the other ones in the same folder) has an incorrect size of 2046 x 2046. I wonder why Oolite doesn't complain about that as well.

Posted: **Wed Feb 29, 2012 11:35 pm**

Lestradae wrote:
Thing is, the Orisis according to pagroove is not supposed to have missiles at all.

Pagroove is wrong. Check the shipdata:

Code: Select all

	<key>PAGroove-Orisis</key>
	<dict>
...
		<key>missile_launch_position</key>
		<string>0 0 0</string>
		<key>missiles</key>
		<string>4</string>

I rest my case.

Posted: **Thu Mar 01, 2012 1:00 am**

Ok but the chances of the crash could be more related due to heavy traffic and memory. I never had the Orisis.oxp crash.

Posted: **Thu Mar 01, 2012 7:29 am**

I tested the crashing scenario with Orisis taken out. It is not that.

The crashes are entirely reproducible on my machine by using the chain hyperjump (jump-optimised) piece of oxp-equipment. I make a series of jumps and look how far I get. Usually, with bad luck at the very first jump, with good luck at the third jump (in which case the planet has no texture) I get the CTD immediately when or a second after coming out of witchspace.

Of twenty or so CTDs I had this way, only one was not after witchspace. The game usually also crashes after max three jumps if they are not immediately following each other. The one exception happened when flying out of the main station after three consecutive jumps had worked.

I envy you, Eric, for your 64 bit. I really hope someone comes along and makes a shiny 64 bit version for windows, too.

Oolite Bulletins

Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report

Re: Getting crashes always ending with bigships report