ringworld

[marc]

Ive got it!
The ringworld bug is related to the Magnitude Limit as well!

First I placed an albedo in each of the ssc entries in the ringworld.ssc file.
This albedo entry was not there before.

Code: Select all

"Ring Section 1" "HD 512"
{
   
   
   Radius    1331597.452 #1.02au tan 1
   EllipticalOrbit {
      Period  0.0249589    # 9.11/365
      SemiMajorAxis   1.02 #au 153000000 km
      ArgOfPericenter  1
      }
   Albedo 0.001
   RotationOffset    1
}


Then I turned the magnitude Limit down to its minium (0.8 ) then made the approach to HD 512 and the ringworld worked without crashing!
I did the same with the Magnitude Limit at 3.20 and it still worked.
Then at 5.20 and it crashed.

Chris, do you think you could fix this?
The same problem occurs with my MySQL version of celestia so I ran the debug version with the debugger.
Here are some screenshots of the debugger in different contexts (vecmath.h,intersect.h and render.cpp) at the point of the crash.

http://mostlyharmless.sourceforge.net/p ... crash1.gif
http://mostlyharmless.sourceforge.net/p ... crash2.gif
http://mostlyharmless.sourceforge.net/p ... crash3.gif
http://mostlyharmless.sourceforge.net/p ... crash4.gif

and here is the ssc file that I used to cause the crash.
http://mostlyharmless.sourceforge.net/p ... _hd512.zip

Im guessing here, is it geting into a deadlock when calculating the closer object? What do you think?
Can you reproduce it?

Marc

[marc]

i rememebr on add-on that i wanted to try once... it was an elevator or something like that. it was like an elevator to a space station orbitin erath. the point is that it also was fromed by lots of *.3ds parts. i have neber seen it yet. it always crashes. maybe there is a problem when using lots of 3ds models. i tryed the elevator with only som of the parts and it didnt crashed.

Im glad to hear that, the elevator crashed for me too. I hope Chris can make some sense of this bug.

[jamarsa]

The elevator *did* work for me flawlessly.

Ringworld crashes for me at a magnitude of 1.83, so I think this may be only a sympthon of the problem.

I was just testing, and the Ringworld don't always crash when going to HD 512. I was able to see it a couple of times, and only crash when I go to HD 512 from another star. If I travel between ring segments, there is not problem at all.

I haven't many addons, only a few 3DS models of spaceships and the Rosetta Nebula. Certainly I never installed the 'Moon everywhere' files.

In one of my tests, went from Sol to HD 512 a couple of times without crashing. Two of the tests didn't crash, but the program started to fill all my memory and swap space (and CPU too), and the program got kicked out by the kernel (by egoism, I presume )

These are my specs:

Intel Pentium 2.4 GHz
256 MB RAM
nVidia Riva TNT2 64 Mb.
Linux Mandrake 9.0/KDE 3.1.

Celestia 1.3.0 (compiled from CVS)


OpenGL info:

Damn it!!! I have no OpenGL info in "About celestia..." of KDE celestia 1.3.0!!! Where is it?? Christophe, please help me!!!

Bah, after all, it was a rather small list of features: no specular, no bumpmaps, no compressed textures, and only 2048 texture .

Oops, my mistake, I just found it in "Configure celestia..." here it is:

Vendor : NVIDIA Corporation
Renderer : RIVA TNT2/AGP/SSE2
Version : 1.4.0 NVIDIA 41.91
Max simultaneous textures: 2
Max texture size: 2048

Supported Extensions:
GL_ARB_imaging
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_texture_env_add
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_IBM_texture_mirrored_repeat
GL_KTX_buffer_region
GL_NV_blend_square
GL_NV_fog_distance
GL_NV_packed_depth_stencil
GL_NV_texgen_reflection
GL_NV_texture_env_combine4
GL_SGIS_multitexture


A little backtrace kindly given by KDE (but not very informative, I fear):

0x4125f739 in wait4 () from /lib/i686/libc.so.6
#0 0x4125f739 in wait4 () from /lib/i686/libc.so.6
#1 0x412dc340 in sys_sigabbrev () from /lib/i686/libc.so.6
#2 0x41194a73 in waitpid () from /lib/i686/libpthread.so.0
#3 0x405e63ed in KCrash::defaultCrashHandler(int) ()
from /usr/lib/libkdecore.so.4

I will try to give a better b-trace if I get Kdbg to work with celestia (I don't know if it's possible to do it, as complains something about DCOP server not working, I am working in Gnome now, tough).

Hope to have been a little help.

[jamarsa]

Another interesting test...


1) I turn off Planet Textures, as ElPelado suggests. Magnitude of 6.83.
2) Hit 'Enter', type 'HD 512', 'Enter' and 'G'.
3) HD 512 in sight, without ring.
4) Turn Planet Textures on again. OK, ringworld is here!!
5) Start to hit 'End', until ringworld starts to blend with the star's glow.
6) Then hit 'End' carefully, step by step, until i am a couple of ly's away.
7) If all goes well, then I'm able to return successfully at any speed, both by hitting 'Home' and by 'G'oing to another star, Sun included, and returning to HD 512 with 'G', always with Planet Textures on. No crash until I restart the program and try go 'G' with textures.

?Maybe there is something related to a table memory allocation? No time to allocate it, and it crashes whenever there are too many objects involved?

See if you can repeat this test...

[marc]

It tried this out and it still crashes for me at step 6.

[jamarsa]

Running this test in my other machine, a Windows XP one, fails in step 6 too always, even turning stars off. But it doesn't crash, only keeps busy, and my Task Manager gives an CPU load of 100% until I close the celestia process. Memory allocation, however, is about 44Mb. It always happen at a distance of between 70-105 AU, no matter what I do. I even tested at 320x240x16 . Is there any switch in the viewing conditions at this distance?

This machine's specs:

Intel Pentium 4 2.4 GHz.
256 Mb RAM
ATI Rage 128 Pro II, 32 Mb
Winders Windows XP Pro (and Linux too, but not running now )

OpenGl info:

Vendor: ATI Technologies Inc.
Renderer: RAGE 128 Pro Ultra x86/SSE2
Version: 1.2.1652 WinXP Release
Max simultaneous textures: 2
Max texture size: 1024

Supported Extensions:

GL_ARB_multitexture
GL_ARB_texture_border_clamp
GL_ARB_texture_env_add
GL_EXT_texture_env_add
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ATI_texture_mirror_once
GL_ATI_vertex_shader
GL_ATI_vertex_streams
GL_ATIX_vertex_shader_output_point_size
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_packed_pixels
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texgen_reflection
GL_EXT_texture3D
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_combine
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_object
GL_EXT_vertex_array
GL_KTX_buffer_region
GL_ARB_window_pos
GL_NV_texgen_reflection
GL_SGI_texture_edge_clamp
GL_SGIS_texture_border_clamp
GL_SGIS_texture_lod
GL_SGIS_multitexture
GL_WIN_swap_hint
WGL_EXT_extensions_string
WGL_EXT_swap_control

[chris]

I'm downloading the Ringworld add-on now to see if I can debug this.


Update: it turns out the Celestia is hanging while sorting objects by distance. The problem I believe is that I changed the predicate for depth sorting of objects to one that's not guaranteed to be transitive. Unfortunately, I can't just revert to the old one because the new predicate solved a very annoying depth sorting bug . . . I'm not sure how to fix it yet.



Second update: Changing the sort function from sort to stable_sort eliminates the crash. But, I haven't thought through the robustness of this fix--does it work only because of the peculiarities of VC 6.0's implementation of stable_sort? Or does the essential property of stable_sort--preserving the order of equal elements--ensure that it will always work.


--Chris

[MrBatman]

I can see the Ringworld just fine ... until I zoom out to about 86 A.U., then Celestia locks up. Is that what you guys are talking about?

[jamarsa]

Yes, exactly that...

It's nice to know that you have found the cause. Thanks, chris!!

[the bluemarble guy]

space elevator works, ringworld doesn't

[marc]

Excellent. thanks Chris , and thanks for all the confirmations guys.

[marc]

Chris, how is progress on this bug going? Is it likely to be fixed by 1.3.1?

Marc.

[chris]

Chris, how is progress on this bug going? Is it likely to be fixed by 1.3.1?

Marc.

Yes . . . in the meantime, you can fix it by editing render.cpp and replacing the call to sort with stable_sort.

--Chris

[MrBatman]

Where is render.cpp? I don't see it anywhere in my Celestia folders, even hidden.

[julesstoop]

It's prolly part of the source.

[marc]

Your right Jules, render.cpp is part of the source code.

Ive done some testing with and without the stable_sort fix. I managed to make all the following addons crashed without it. Good news is they all work fine with the fix on my system. (see above for specs)

Lunar Landing Sites (Jack Higgins)
Space Lift (puduku)
Geostationary_full, Iriduim and GlobalStar (combined, puduku)
Ringworld (me)

thanks again Chris.

[ElPelado]

so marc, now that it works, can you explain me how to make that fix?

[jamarsa]

El Pelado wrote:

so marc, now that it works, can you explain me how to make that fix?

You have to modify the source code. As I understand, you need Microsoft Visual C++ Development to do a recompile if you want the fix. Perhaps in a few days chris would give us a modified binary pre-release... Or perhaps marc would send you the executable

[ElPelado]

ah, ok ok.
so i will wait

[jamarsa]

Aunque siempre puedes intentar aprender un poquillo de programaci?n sobre Linux (total, es gratis!! ).

Translation for others (I didn't resist the temptation to post a little in Spanish, sorry )
You can also try to learn a little about programming over Linux (it's really free!!)