[Solved] wormholes in interstellar space not quite fixed yet

[Cody]

Encountered this problem yesterday with McLane's Wormhole Restoration OXP and a zero-distance pair, in Oolite 1.75.2

I forced a misjump between two zero-distance systems, splashed the warships and jammers... the wormhole was restored, but I couldn't ID it or use it.
All I could do was fly right through it. Should I try this in trunk, or has it been fixed?

[JensAyton]

has it been fixed?

Nope.

[JensAyton]

The problem with unselectable wormholes should be fixed in r4561. There are two fixes:

• The effective travel distance of a wormhole cannot be less than 0.1 LY, which is self-consistent in any case.
• Wormholes whose “witch mass” has shrunk to zero are no longer drawn. (They weren’t supposed to be, and this is what caused ghost wormholes.)

There is now a problem where wormholes disappear (instead of becoming ghosts) well before their estimated vanishing time per the wormhole scanner, without a shrinking effect. This is caused by a discrepancy between two different internal countdown mechanisms, the “witch mass” and the “expiry time”. This seems to be an old bug. Ideally, the time-to-live would be calculated based on “witch mass” and “shrink rate” instead of trying to track it separately.

McLane, please try to recreate your original bug with this revision (tonight’s nightly).

[Commander McLane]

McLane, please try to recreate your original bug with this revision (tonight’s nightly).

I just made some trials with r4562 and can confirm that the bug as reported in this thread has been squashed. All wormholes in subsequent misjumps are targetable and in good working condition.

[DaddyHoggy]

McLane, please try to recreate your original bug with this revision (tonight’s nightly).

I just made some trials with r4562 and can confirm that the bug as reported in this thread has been squashed. All wormholes in subsequent misjumps are targetable and in good working condition.

Thread title changed to reflect resolution.

[Switeck]

I just made some trials with r4562 and can confirm that the bug as reported in this thread has been squashed. All wormholes in subsequent misjumps are targetable and in good working condition.

I fear I've run into a game crash that may be distantly related to the older crashes concerning interstellar space wormholes.

After misjumping a lot...typically when I then jump to a regular system, the game crashes.
This is the error message I'm getting:
12:07:06.031 [log.header]: Opening log for Oolite development version 1.75.3.4564 (x86-32 test release) under Windows at 2011-06-20 12:07:06 -0500.
4 processors detected.
...
12:13:27.859 [exception]: ***** Exception during [manageCollisions] in -[PlayerEntity update:] : NSInternalInconsistencyException : NSIncrementExtraRefCount() asked to increment too far *****

The problem seems far worse if the clock at the bottom is (adjusting) when starting another jump. Even if the game doesn't crash...it takes far longer (real time) to complete the jump. I've found myself wondering if the game's crashed or if it'll finally jump over 20 seconds later. Sometimes it DOES finish the jump 1-5 minutes after it started!

From chatting on irc:

Code: Select all

[11:04]	<mikembp>	i'm going to guess that it crashes on this line:
[11:04]	<mikembp>	ent = [(Entity *)[collidingEntities objectAtIndex:0] retain];
[11:05]	<mikembp>	its the retain that affects the refcount
[11:07]	<Switeck>	Could my ship colliding with a wormhole possibly cause that problem?
[11:08]	<mikembp>	no idea, i'm really not that familiar with the oolite code base
[11:09]	<mikembp>	i would advise to get a debug build of the game so that you can find the exact conflicting line
[11:10]	<Switeck>	I haven't a clue how
[11:14]	<Switeck>	http://prdownload.berlios.de/oolite-linux/oolite-debug-console-1.0.zip <- this?

I've only run console briefly and don't know how to use it to debug.

[JensAyton]

If you can reproduce the problem, it would be helpful if you could run with the NSZombieEnabled environment variable set to YES. For Windows, I think you can do it like this at the command prompt, although I’m not sure I have the file name right:

Code: Select all

set NSZombieEnabled=YES
oolite.app\oolite.exe

For reference, the Linux equivalent would be something like:

Code: Select all

NSZombieEnabled=YES oolite.app/oolite

Note: when running in this mode, Oolite will consume a lot of memory, and will eventually run out and crash.

[Switeck]

Ok, what am I looking for when I do this?
My OXP creates an npc ship (a missile of all things!) and immediately has that missile make a wormhole to a nearby system...since this is so close to the front of my ship, my ship almost instantly enters it.

Game then crashes,
OoDebugConsole.exe returns this message:
Connection closed with no message.

stderr.txt and stdout.txt are both empty -- 0 KB in size.

The last entry in Latest.log contains only the debugging messages my OXP is making concerning which system the npc ship is making a wormhole to:
02:42:17.296 [jumpDis ]: 6.8, lastJump , 61, current loc , (26.8, 18.6, 0), current X,Y , 26.8, 18.6, Destination X,Y , 31.6, 23.8, ver 2 X,Y , (31.6, 23.8, 0)

And nothing else.

...Ok, in repeating the tests I have "weapons system offline." covering the missile pylon indicator icons. I have no missiles loaded, yet during/after some of the jumps I'm seeing the missile icons flash brightly and/or dimly...and in red, green, or even blue colors! What's weird about that is it doesn't happen every time, but seems to happen with each crash...though it often happens even when there's not a crash. Graphical red herring?

...And trying again, I finally got this:
09:06:19.875 [exception]: ***** Exception during [manageCollisions] in -[PlayerEntity update:] : NSInternalInconsistencyException : NSIncrementExtraRefCount() asked to increment too far *****
Once again, OoDebugConsole.exe returns this message:
Connection closed with no message.
And stderr.txt and stdout.txt are both empty.

Ok, problem seems related to this:
https://bb.oolite.space/viewtopic.php?f=3&t=10204
...which doesn't involve wormholes at all.

[JensAyton]

This should be fixed in the latest nightly. I can now do sixty interstellar jumps in a row without trouble (and without each being slower than the last).

[Switeck]

I tested it too...and it seems to work ok.

[Switeck]

Sadly, wormholes in interstellar space are possibly not quite fixed yet.

I'm still getting CTDs with the latest windows nightly build of Oolite concerning the use of npc wormholes in interstellar space.
Using:
oolite-trunk-1.75.4.4651-dev.win32.exe
On Win XP Pro SP3.

Program received signal SIGSEGV, Segmentation fault.
0x0412e891 in ?? ()
(gdb) bt
#0 0x0412e891 in ?? ()
#1 0x00000038 in ?? ()
#2 0x03940000 in ?? ()
#3 0x000001c0 in ?? ()
#4 0x039a3000 in ?? ()
#5 0x69d937bd in nvoglnt!DrvValidateVersion ()
from C:\WINDOWS\system32\nvoglnt.dll
#6 0x039a3000 in ?? ()
#7 0x00000000 in ?? ()


My google searches on the subject are troubling:
http://www.gamedev.net/topic/488640-gle ... em-solved/
"it seemed that the code i had to read in the shader caused there to be some random data in the string. This was causing compile errors and as i had no error checking was causing the crash i belive."
http://forums.amd.com/forum/messageview ... did=133848
http://www.gamedev.net/topic/433962-nvi ... 2dmipmaps/
Missing , typo caused the error.

This happens even when I have shaders disabled.

Latest svn debug compile (version 4652) of Oolite also crashes to desktop.

Program received signal SIGSEGV, Segmentation fault.
0x048ee6b8 in ?? ()
(gdb) bt
#0 0x048ee6b8 in ?? ()
#1 0x00000038 in ?? ()
#2 0x04100000 in ?? ()
#3 0x00000070 in ?? ()
#4 0x04163000 in ?? ()
#5 0x69d937bd in nvoglnt!DrvValidateVersion ()
from C:\WINDOWS\system32\nvoglnt.dll
#6 0x04163000 in ?? ()
#7 0x00000000 in ?? ()

stderr.txt and stdout.txt are both 0-byte files.

[another_commander]

To me it looks like something is going horribly wrong with your graphics drivers rather than Oolite itself. You seem to be getting similar gdb backtraces for any and all crashes you have reported recently, all of them (backtraces) invoving graphics driver code.

Is the crash with the wormholes reliably reproducible, i.e. does it happen each and every time you are try to ride on one?

[Kaks]

The Thargoid escorts bug was an extremely good find! And one that's been keeping me off the streets for 3 days already, so do keep up the good work!

There's one other thing to check, if you don't mind!

Assuming you can reproduce this crash at will, does this crash still happen if you're running Oolite without gdb?
If not we'll happily file this under the 'aaah gdb!' heading...

[another_commander]

One thing to note, just to cover all cases: gdb does not like being run with the application being debugged in full screen. Windowed mode is the recommended way for debugging.

[Switeck]

To me it looks like something is going horribly wrong with your graphics drivers rather than Oolite itself. You seem to be getting similar gdb backtraces for any and all crashes you have reported recently, all of them (backtraces) invoving graphics driver code.

While I have gotten other CTDs lately, most of the others have both been reported by other people and not been shown to be caused by faulty video drivers. In fact, the ONLY matches I found on this forum for nvoglnt.dll was the posts I made on this thread.

Is the crash with the wormholes reliably reproducible, i.e. does it happen each and every time you are try to ride on one?

Yes and no. But it happens often enough it's beyond coincidence. What I am testing makes a few regular jumps and a lot of misjumps. It regularly crashes...but often not at the same place. Sometimes it may do over 20 misjumps before it encounters a crash...other times it doesn't manage to make 3 before a crash.

The unpredictable timing of these crashes convince me that the crash trigger may not be wormholes directly, as I have other similar OXPs which do not crash. It is possible that the crash is simply a very weird bug done by me in my OXP, but I simply cannot glean enough information out of the game's crashes + logs to narrow down how/why/where the crash is triggered.

There simply isn't enough information in Latest.log to tell much about the crash:

16:34:43.875 [log.header]: Opening log for Oolite development version 1.75.4.4651 (x86-32 test release) under Windows at 2011-11-18 16:34:43 -0600.
4 processors detected.
Build options: spoken messages, mass/fuel pricing, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.

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

16:34:43.937 [display.mode.list.native]: Windows native resolution detected: 1360 x 768
16:34:43.984 [joystick.init]: Number of joysticks detected: 0
16:34:44.000 [searchPaths.dumpAll]: Unrestricted mode - resource paths:
Resources
../AddOns
../AddOns/Basic-debug.oxp
../AddOns/Misjump Inducer v0.2.oxp
../AddOns/OMEGA.oxp
../AddOns/OneWayTicket2Oresrati v0.43 STRIPPED.oxp
../AddOns/SwiteckAutojumper v0.53.oxp
../AddOns/Wormhole maker v0.53.oxp
16:34:44.000 [rendering.opengl.version]: OpenGL renderer version: 2.1.0 ("2.1.0 - Build 6.14.10.5303"). Vendor: "Intel". Renderer: "Intel(R) G41 Express Chipset".
16:34:44.000 [rendering.opengl.extensions]: OpenGL extensions (83):
GL_ARB_texture_env_crossbar, GL_EXT_abgr, GL_ARB_shadow, GL_IBM_texture_mirrored_repeat, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_EXT_blend_minmax, GL_EXT_draw_buffers2, GL_ARB_texture_env_add, GL_EXT_framebuffer_blit, GL_EXT_transform_feedback, GL_ARB_texture_env_dot3, GL_EXT_framebuffer_object, GL_EXT_blend_subtract, GL_3DFX_texture_compression_FXT1, GL_NV_conditional_render, GL_ARB_multitexture, GL_EXT_stencil_wrap, GL_ARB_texture_border_clamp, GL_ARB_framebuffer_sRGB, GL_ARB_texture_env_combine, GL_EXT_texture_env_add, GL_EXT_packed_pixels, GL_SGIS_texture_edge_clamp, GL_ARB_depth_texture, GL_SGIS_texture_lod, GL_ARB_occlusion_query, GL_ARB_transpose_matrix, GL_NV_texgen_reflection, GL_EXT_stencil_two_side, GL_ARB_shading_language_100, GL_ARB_texture_compression_rgtc, GL_EXT_texture_shared_exponent, GL_EXT_rescale_normal, GL_ARB_pixel_buffer_object, GL_EXT_secondary_color, GL_ARB_half_float_pixel, GL_EXT_blend_equation_separate, GL_EXT_draw_range_elements, GL_EXT_texture_lod_bias, GL_EXT_texture_filter_anisotropic, GL_ARB_half_float_vertex, GL_EXT_texture_swizzle, GL_SGIS_generate_mipmap, GL_ARB_texture_rectangle, GL_ARB_texture_non_power_of_two, GL_ARB_point_sprite, GL_EXT_packed_depth_stencil, GL_ARB_vertex_shader, GL_EXT_texture_compression_s3tc, GL_ARB_depth_buffer_float, GL_ARB_draw_instanced, GL_ARB_vertex_buffer_object, GL_WIN_swap_hint, GL_ARB_color_buffer_float, GL_ARB_shader_objects, GL_ATI_separate_stencil, GL_ARB_framebuffer_object, GL_EXT_packed_float, GL_EXT_texture_rectangle, GL_ARB_texture_rg, GL_ARB_fragment_shader, GL_EXT_fog_coord, GL_EXT_texture3D, GL_ARB_window_pos, GL_ARB_fragment_program, GL_ARB_vertex_program, GL_EXT_texture_env_combine, GL_ARB_point_parameters, GL_ARB_texture_cube_map, GL_EXT_bgra, GL_EXT_compiled_vertex_array, GL_ARB_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_texture_compression, GL_EXT_multi_draw_arrays, GL_ARB_texture_float, GL_EXT_blend_func_separate, GL_EXT_texture_sRGB, GL_EXT_shadow_funcs, GL_EXT_clip_volume_hint, GL_EXT_blend_color, GL_NV_blend_square
16:34:44.031 [rendering.opengl.shader.support]: Shaders are supported.
16:34:44.031 [speech.synthesis]: Spoken messages are off.
16:34:44.234 [script.load.world.listAll]: Loaded 8 world scripts:
oolite-cloaking-device 1.75.4
oolite-constrictor-hunt 1.75.4
oolite-nova 1.75.4
oolite-thargoid-plans 1.75.4
oolite-trumbles 1.75.4
owt2o_jumper 0.42.1 - for Oolite 1.75 and later
swi_autoJumper 0.53.15 - for Oolite 1.75 and later
swi_Jumper 0.54 - for Oolite 1.75 and later
16:34:45.218 [loading.complete]: ========== Loading complete. ==========
16:34:45.218 [debugTCP.connected]: Connected to debug console "DebugConsole".
16:34:48.515 [script.load.world.listAll]: Loaded 8 world scripts:
oolite-cloaking-device 1.75.4
oolite-constrictor-hunt 1.75.4
oolite-nova 1.75.4
oolite-thargoid-plans 1.75.4
oolite-trumbles 1.75.4
owt2o_jumper 0.42.1 - for Oolite 1.75 and later
swi_autoJumper 0.53.15 - for Oolite 1.75 and later
swi_Jumper 0.54 - for Oolite 1.75 and later
16:35:05.968 [1]: 93,5118,5184,6232,1183,5183,5040,5206,1118
16:35:05.968 [1]: 5.6, 118, 5118
16:35:05.968 [2]: 18, 184, 5184
16:35:05.968 [3]: 12.8, 232, 6232
16:35:05.968 [3]: 12.8, 232, 5232
16:35:05.968 [4]: 6, 183, 1183
16:35:06.171 [5]: 4, 183, 5183
16:35:06.171 [6]: 10.8, 40, 5040
16:35:06.171 [7]: 21.2, 206, 5206
16:35:06.171 [8]: 6.8, 118, 1118

Assuming you can reproduce this crash at will, does this crash still happen if you're running Oolite without gdb?
If not we'll happily file this under the 'aaah gdb!' heading...

Yes -- this crash happened when running Oolite normally, so there's no backtrace information to go with it. It just Crashes-To-Desktop (CTD) at roughly the same spot as happened when running Oolite with GDB.

I can package up ALL of my OXPs shown here, and my savegame, and my Log files if that will do any good...but it will require probably an hour of work just to get them in a presentable form. But some of what I'm working on is of a somewhat secret and esoteric nature that I would greatly prefer to PM links to devs rather than posting links here.