Crash at Esusti

[Garrett]

Dear fellow Ooliters,

I am playing the latest release (v.1.73.4) in Windows XP x64, and OOlite keeps crashing at the planet Esusti whilst I am in open space with no ships on the scanner.

I think the problem is in Commies OXP, as I do not get the crash when the OXP is removed (ie I play Vanilla OOlite) but do get the crash when Commies is the only OXP installed (along with the WolfMkII OXP which I need since I'm flying a Wolf Mk II).

The stderr file:

Code: Select all

ALERT ... GSCurrentThread() ... objc_thread_get_data() call returned nil!
Your application MUST call GSRegisterCurrentThread() before attempting to
use any GNUstep code from a thread other than the main GNUstep thread.

and the log file:

Code: Select all

[log.header]: Opening log for Oolite version 1.73.4 (x86-32 test release) under Windows at 2009-10-14 06:34:46 +0100.
4 processors detected.
Oolite Options: [Procedural Planets] [Docking Clearance] [Wormhole Scanner] [Target Incoming Missiles]

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[joystickHandler.init]: Number of joysticks detected: 0
[display.mode.list.native]: Windows native resolution detected: 1280 x 1024
[rendering.opengl.version]: OpenGL renderer version: 2.1.2 ("2.1.2")
Vendor: NVIDIA Corporation
Renderer: GeForce 7950 GT/PCI/SSE2
[rendering.opengl.extensions]: OpenGL extensions (125):
GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 
[searchPaths.dumpAll]: ---> OXP search paths:
(Resources, ../AddOns, ../AddOns/Commies.oxp, ../AddOns/wolfmk2.oxp)
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[shipData.load.begin]: Loading ship data...
  [shipData.load.warning.badFlasher]: ----- WARNING: the shipdata.plist entry "comlimesc" has a broken flasher definition "*FLASHER*" (should have 8 tokens, has 5). This flasher will be ignored.
  [shipData.load.error.badSubentity]: ***** ERROR: subentity declaration for ship comlimesc specifies no subentity_key.
  [shipData.load.warning.badFlasher]: ----- WARNING: the shipdata.plist entry "comlimesc" has a broken flasher definition "*FLASHER*" (should have 8 tokens, has 6). This flasher will be ignored.
  [shipData.load.error.badSubentity]: ***** ERROR: subentity declaration for ship comlimesc specifies no subentity_key.
  [shipData.load.warning.badFlasher]: ----- WARNING: the shipdata.plist entry "comlimesc" has a broken flasher definition "*FLASHER*" (should have 8 tokens, has 6). This flasher will be ignored.
  [shipData.load.error.badSubentity]: ***** ERROR: subentity declaration for ship comlimesc specifies no subentity_key.
  [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dock-factory" specifies non-existent model "comfactory_dock.dat".
[script.load.world.listAll]: Loaded 6 world scripts: "communist_population", "oolite-cloaking-device" 1.73.4, "oolite-constrictor-hunt" 1.73.4, "oolite-nova" 1.73.4, "oolite-thargoid-plans" 1.73.4, "oolite-trumbles" 1.73.4
[dataCache.willWrite]: About to write data cache.
[dataCache.write.success]: Wrote data cache.

The REALLY strange thing is that I only have this crash in the Communist world Esusti, and it is repeatable (it happens every time I go through there), but I've not noticed it with any other communist worlds. I will try and find some and see if it affects any otherts.

I tried searching for Esusti in the forums, but could only find a report of a memory leak, but the memory manager in Windows reports a fairly stable 280Mb memory usage.

Judging by my previous crash (see my last Topic) it may be the Error in the log file (i.e. the dock-factory error) since it can't find the model for the ship.

Many thanks!

[another_commander]

You have errors in the Commies OXP (broken flasher definitions and bad shipdata entries in general). These should be first corrected to see if the crash persists, then we should investigate why the crash happens in the first place.

[Garrett]

OK, I haven't edited the commies OXP, but I will try re-downloading from the OXP wiki site and see if it makes things better.

Thanks for the quick response!

[Chrisfs]

I think I have visited Esusti with Commies on and haven't crashed but I'll try it again in a few days and let you know

[Eric Walch]

OK, I haven't edited the commies OXP, but I will try re-downloading from the OXP wiki site and see if it makes things better.

In the current release on the wiki [v2.08], those flashers should have been fixed. When not, please report.
The original Author (dr. nil) has the broken version on his site. But he has still unread mail from me that is a half year old, about this and other oxp's of his.

[Garrett]

I downloaded the latest version that Eric suggested (I previously had the earlier version from the author's website). The errors in the log file seem to have gone with the newer version, but I still get a crash when I attempt to sun-skim at Esusti - I witchspace in to the system, locate the sun, fly towards it, and the game crashes with no ships on the scanner.

Here is the log file:

Code: Select all

[log.header]: Opening log for Oolite version 1.73.4 (x86-32 test release) under Windows at 2009-10-15 06:57:37 +0100.
4 processors detected.
Oolite Options: [Procedural Planets] [Docking Clearance] [Wormhole Scanner] [Target Incoming Missiles]

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[joystickHandler.init]: Number of joysticks detected: 0
[display.mode.list.native]: Windows native resolution detected: 1280 x 1024
[rendering.opengl.version]: OpenGL renderer version: 2.1.2 ("2.1.2")
Vendor: NVIDIA Corporation
Renderer: GeForce 7950 GT/PCI/SSE2
[rendering.opengl.extensions]: OpenGL extensions (125):
GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 
[searchPaths.dumpAll]: ---> OXP search paths:
(Resources, ../AddOns, ../AddOns/Commies.oxp, ../AddOns/wolfmk2.oxp)
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[shipData.load.begin]: Loading ship data...
[script.load.world.listAll]: Loaded 6 world scripts: "communist_population" 2.08, "oolite-cloaking-device" 1.73.4, "oolite-constrictor-hunt" 1.73.4, "oolite-nova" 1.73.4, "oolite-thargoid-plans" 1.73.4, "oolite-trumbles" 1.73.4
[dataCache.willWrite]: About to write data cache.
[dataCache.write.success]: Wrote data cache.

I'm guessing it's a similar issue to the one I had before with the Asp Mk II Special i.e. a ship model .dat file using multiple texture files - for some reason my unusual version of Windows (XP x64) doesn't like these things (see my Topic earlier) whereas it seems happy on other people's operating systems.

Thanks for the help!

[Screet]

for some reason my unusual version of Windows (XP x64) doesn't like these things (see my Topic earlier) whereas it seems happy on other people's operating systems.!

For me, the only big difference the OS do make is this: If they have Data Execution Prevention switched on the OS will crash the app when it's doing something wrong while without DEP the app may work although it's doing something wrong.

Could you please check wether you have DEP switched on for all programs and if so try to make an exception for Oolite there and see if this solves your problem?

Screet

[Eric Walch]

I just visited that system:

Code: Select all

Average Industrial, Tech level 10
planet radius 5253 km
solar radius 15950 km

It is a system with a big sun. It resembles a situation Micha brought up to me just yesterday. In some systems the "collective ZGF" (slapu) station heats up to much because it is to close to the sun. Objects closer than 2.5 solar radii to the sun eventually explode. I calculated it for this system:

Code: Select all

> system.sun.radius
159507.296875

> player.ship.target.position.distanceTo(system.sun)
387467.34375

> player.ship.target.position.distanceTo(system.sun) / system.sun.radius
2.429151213399622

> player.ship.target.position.distanceTo(system.sun)/system.mainPlanet.position.distanceTo(system.sun)
0.35124355229624427

(player.ship.target is the station here)

While writing this, heat of that station is already 60% of max. I have no idea if this could be related to a crash though. But please go to the sun and look if there is a correlation with that station there. Those stations are only present in dictatorships of tech level 10 or higher. This system qualifies. (To Micha: I now re-centred that station)

It heats up because al stations of this type are placed at 35% from the sun at the sun-planet lane. Calculating the distance shows the station is placed there correctly but for this system it is still to close. It should have used "sps" coordinates instead of "spu" coordinates. I never would have thought that 35% could be to close.

[Screet]

While writing this, heat of that station is already 60% of max. I have no idea if this could be related to a crash though. But please go to the sun and look if there is a correlation with that station there.

I did see such stations blow up due to heat in the past. One very annoying experience was when it did blow up in the moment when I was about to dock

However, at least back then, it did not crash my system, but I cannot remember if I really had DEP switched on at that time.

Screet

[Eric Walch]

I did see such stations blow up due to heat in the past. One very annoying experience was when it did blow up in the moment when I was about to dock

I also can't believe there can be a relation, but this is something special about this system. And a bug I will correct.
After half an hour the heat is now at 80% (nice colour red for the station now). So overheating is not that fast. I can imagine that there might be others that are even a bit closer to the sun.

In this system it won't even blow up because when I set temperature at 99% it vents heat until it cools down to 83 %. So for this system it is just on the save side of the heat-up/cool-down equilibrium.

[Kaks]

For me, the only big difference the OS do make is this: If they have Data Execution Prevention switched on the OS will crash the app when it's doing something wrong while without DEP the app may work although it's doing something wrong.

This ominous 'something wrong' seems to actually mean 'allows oxps to keep using timers'.

While you still have my eternal gratitude (for another few days at least) for discovering why windows sometimes really don't like timers, the random doom mongering really puzzles me.

If you've already got a patch that would neatly stop Oolite from clashing with DEP, I for one would be very interested to hear about it. One option we have - of course - is to remove timers altogether from the js implementation, so no OXPs can use this very much accident prone feature. It would kill a few very much liked OXPs though.

If the crashes Garrett is experiencing are related to what happened with the asp from x-ships, we're still trying to figure out what exactly is happening there, since having 2 (or more) textures for ships shouldn't have anything to do with crashing Oolite. Of course we're hampered by the fact none of the developers have got XP 64 bit, which of course seems to behave slightly differently to either the more common XP (32 bits) or Vista 64 bits.

Finally, yes Oolite has bugs. We are very aware of that, and if you look at the svn logs - say for the last month or so - you might notice dozens of fixes for bugs that weren't even mentioned on the boards / bug tracker, but simply found and corrected by the various people working on the project. If a particular bug ...err... bugs you, you're more than welcome to find and show us a solution. All of us working on Oolite have got real jobs and other commitments too, and only mange to work on it if / when circumstances allow.

Somewhere else you told us that another game (the one you are developing for a selected group of friends) was running foul of DEP, and you managed to solve that issue.
Once again, much appreciated if you could let us know what the root problem was, and how you actually solved it. Who knows, it might even help with our timers issues.

[Lestradae]

... if you look at the svn logs - say for the last month or so - you might notice dozens of fixes for bugs that weren't even mentioned on the boards / bug tracker, but simply found and corrected by the various people working on the project. ...

Don't think this isn't noted with (temporarily) eternal gratitude by some people here, amongst them me, for example, Kaks!

You devs are doing a great job, Oolite core has massively and - on my system, very noticably - become better and better this year.

Perhaps all of that should be mentioned from time to time

Keep up the good work by all means

L

[Chrisfs]

For what it's worth. I visited Esusati today with 1.73.4 using Commies OXP and didn't explode. Am jealous though. While I ahve seen a bunch of Astromine Gulags, I have yet to see a single solar ZPF. I will ahve to visit the sun on Esusati again.

[Kaks]

While I ahve seen a bunch of Astromine Gulags, I have yet to see a single solar ZPF. I will ahve to visit the sun on Esusati again.

Intriguing. Maybe that particular model is what makes Garrett's copy of Oolite crash. Will have a look this evening!

[Garrett]

You devs are doing a great job, Oolite core has massively and - on my system, very noticably - become better and better this year.

Perhaps all of that should be mentioned from time to time

Keep up the good work by all means

L

Yes, I definitely want to say a BIG thank you for this game. The stand-alone version of Oolite works fine in my rather-obscure OS, and so I am happy to play with or without various OXP's, it's still a great game

The reason I posted these crashes are that I know I have an unusual version of Windows, so any crashes I experience from OXP's are likely to not have been met before. Keep up the good work guys, it's much appreciated!

I will try turning off DEP for Oolite and see if it fixes things. If it helps you track down what's going on, the crash happens much quicker when I fly towards the sun (a few seconds of Jumping), whereas flying towards the planet makes it happen much later, but still before I get to the Coriolis station.