Opening menus freezes Celestia

[Daedalus]

I have the same problem than this guy here http://www.celestiaproject.net/forum/viewtopic.php?t=3654 but upgrading my drivers didn't solve the problem.
Windows 2000 Service Pack 4
Celestia 1.3.2
Athlon XP 3000+
1024 RAM
Gainward Geforce 6600 GT 256mb with 81.95 drivers

[rdasilva]

I have the same problem on the Linux version using:

- (Open)Suse v10.0 (although I had exactly the same on v9.3)
- AMD 3700
- NVidia G-force 6600 GT (dual DVI) clone (XFX)
- using KDE 3.4.2 Level "b"
- 1GB of RAM (43% free, 66MB free physical memory when running Celestia)

Whenever I choose 'Settings | Configure Celestia' or 'Help | OpenGL info' Celestia (1.3.2) just hangs. All other 'Settings' and 'Help' menu items work OK. Nothing is printed to the terminal window before the crash. Is there any way to turn logging to verbose so we can see what it's trying to do?

[Juffo-Wup]

I have the same problem on the Linux version using:

- (Open)Suse v10.0 (although I had exactly the same on v9.3)
- AMD 3700
- NVidia G-force 6600 GT (dual DVI) clone (XFX)
- using KDE 3.4.2 Level "b"
- 1GB of RAM (43% free, 66MB free physical memory when running Celestia)

Whenever I choose 'Settings | Configure Celestia' or 'Help | OpenGL info' Celestia (1.3.2) just hangs. All other 'Settings' and 'Help' menu items work OK. Nothing is printed to the terminal window before the crash. Is there any way to turn logging to verbose so we can see what it's trying to do?

This has also happened to me with every version of Celestia I have tried from 1.3.2 to 1.4.0. Trying to access "Time -> Set Time" also results in a program freeze. I'm curious how one would proceed to debug this problem since I'm not getting any error output even if I'm running the thing through gdb.

- Gentoo Linux 64bit
- AMD64 3000
- GeForce 6600GT 128MB
- 1GB RAM
- KDE 3.5
- Celestia configured --with-kde --with-lua

[t00fri]

I have the same problem on the Linux version using:

- (Open)Suse v10.0 (although I had exactly the same on v9.3)
- AMD 3700
- NVidia G-force 6600 GT (dual DVI) clone (XFX)
- using KDE 3.4.2 Level "b"
- 1GB of RAM (43% free, 66MB free physical memory when running Celestia)

Whenever I choose 'Settings | Configure Celestia' or 'Help | OpenGL info' Celestia (1.3.2) just hangs. All other 'Settings' and 'Help' menu items work OK. Nothing is printed to the terminal window before the crash. Is there any way to turn logging to verbose so we can see what it's trying to do?

That to me means that some library is presumably buggy .
With that many patches applied (SuSE)...No wonder

It is very probably NOT a Celestia problem. Being a Celestia developer, I am compiling the source code most regularly using KDE-3.4.2 and SuSE 9.0 (->9.3) . I never, really never encounter any (unexplained) crashes.

Did you

1) try compiling the source code yourself?
2) check with 'ldd' whether celestia finds all runtime libraries? I.e.

> ldd `which celestia`

(note /back/ commas!)

Bye Fridger

[rdasilva]

As it also happens with Gentoo (above) it's obviously not just related to Suse, and yes, I compiled everything myself using: 'configure --with-kde'.

ldd `which celestia` returns:
libkio.so.4 => /opt/kde3/lib64/libkio.so.4 (0x00002aaaaabc2000)
libkdeui.so.4 => /opt/kde3/lib64/libkdeui.so.4 (0x00002aaaab048000)
libkdesu.so.4 => /opt/kde3/lib64/libkdesu.so.4 (0x00002aaaab4cb000)
libkwalletclient.so.1 => /opt/kde3/lib64/libkwalletclient.so.1 (0x00002aaaab5e1000)
libkdecore.so.4 => /opt/kde3/lib64/libkdecore.so.4 (0x00002aaaab6f3000)
libDCOP.so.4 => /opt/kde3/lib64/libDCOP.so.4 (0x00002aaaaba4f000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaabbad000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002aaaabcc2000)
libart_lgpl_2.so.2 => /usr/lib64/libart_lgpl_2.so.2 (0x00002aaaabdc5000)
libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002aaaabedc000)
libkdefx.so.4 => /opt/kde3/lib64/libkdefx.so.4 (0x00002aaaac00e000)
libqt-mt.so.3 => /usr/lib/qt3/lib64/libqt-mt.so.3 (0x00002aaaac13a000)
libXrandr.so.2 => /usr/X11R6/lib64/libXrandr.so.2 (0x00002aaaaca66000)
libXcursor.so.1 => /usr/X11R6/lib64/libXcursor.so.1 (0x00002aaaacb6a000)
libXinerama.so.1 => /usr/X11R6/lib64/libXinerama.so.1 (0x00002aaaacc74000)
libXft.so.2 => /usr/X11R6/lib64/libXft.so.2 (0x00002aaaacd76000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00002aaaace8c000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00002aaaacfcb000)
libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x00002aaaad146000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaad26b000)
libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1 (0x00002aaaad380000)
libfam.so.0 => /usr/lib64/libfam.so.0 (0x00002aaaad489000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaad593000)
libpng.so.3 => /usr/lib64/libpng.so.3 (0x00002aaaad78f000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaad8c8000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002aaaad9ea000)
libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x00002aaaadb6f000)
libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x00002aaaadc79000)
libXmu.so.6 => /usr/X11R6/lib64/libXmu.so.6 (0x00002aaaadd95000)
libXi.so.6 => /usr/X11R6/lib64/libXi.so.6 (0x00002aaaadeae000)
libz.so.1 => /lib64/libz.so.1 (0x00002aaaadfb6000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002aaaae0cc000)
libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x00002aaaae27f000)
libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x00002aaaae390000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaae5a0000)
libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaae6a3000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaae7fa000)
libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaae908000)
/lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
libXt.so.6 => /usr/X11R6/lib64/libXt.so.6 (0x00002aaaaeb34000)
libGLcore.so.1 => /usr/lib64/libGLcore.so.1 (0x00002aaaaec96000)
libnvidia-tls.so.1 => /usr/lib64/tls/libnvidia-tls.so.1 (0x00002aaaaf515000)

[t00fri]

I suppose you are using a 64bit CPU, which might be the reason for the problems. In any case, the user Juffo-Wup having similar problems also employs 64bit.

Unfortunately with 64bit specific Linux problems you will be largely on your own, I am afraid. Perhaps Pat Suwalski can help you. I think he has a 64bit machine, too.

Try building the Celestia-gtk version that does not use KDE (which might simply be buggy for 64 bit). Pat develops the gtk-version and probably tested it for 64bit architecture.

You should always take the new 1.4.0 sources that are available for download on SF.

Bye Fridger

[Juffo-Wup]

I just compiled the latest CVS using --with-gtk and the program doesn't hang while accessing the before mentioned menu options.

I also managed to compile the KDE version of Celestia on a x86 Gentoo Linux machine which has the same version gcc and kde as my own. The freezing does not occur with that system.

So it does look like the KDE interface is bugged with 64bit systems.

[Juffo-Wup]

I may have found a fix for this bug.

I started working with the source code and found out out that calling the function getOpenGLInfo() in kdeapp.cpp causes the "Help -> OpenGL Info" menuoption to fail and freeze Celestia. This seemed odd since getting OpenGL info works just fine with the gtk version of Celestia. I checked the corresponding function (actionHelpOpenGL()) in src/celestia/gtk/actions.cpp and made adjustments to kdeapp.cpp based on that.

Basically I changed only 2 lines;
if (ExtensionSupported(const_cast<char*>("GL_ARB_multitexture")))
-> if (ExtensionSupported("GL_ARB_multitexture"))
and
while (pos != string::npos)
-> while (pos != (unsigned int)string::npos)

Patch:

Code: Select all

--- src/celestia/kde/kdeapp.cpp 2005-08-06 12:58:00.000000000 +0300
+++ src/celestia/kde/kdeapp.cpp 2005-12-26 03:34:04.000000000 +0200
@@ -889,7 +889,7 @@

     char buf[100];
     GLint simTextures = 1;
-    if (ExtensionSupported(const_cast<char*>("GL_ARB_multitexture")))
+    if (ExtensionSupported("GL_ARB_multitexture"))
         glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &simTextures);
     sprintf(buf, "Max simultaneous textures: %d\n", simTextures);
     s += buf;
@@ -904,7 +904,7 @@
     {
         QString extString(ext);
         unsigned int pos = extString.find(' ', 0);
-        while (pos != string::npos)
+        while (pos != (unsigned int)string::npos)
         {
             extString.replace(pos, 1, "\n    ");
             pos = extString.find(' ', pos+5);


These changes made the "OpenGL Info" dialog work properly and by extension also "Settings -> Configure Celestia" since it contains an OpenGL configuration page.

Note though that I'm not a programmer, so I have no way of knowing if these changes break anything else, so use them at your own risk!

[suwalski]

Hello, I develop Celestia completely under Gentoo AMD64.

Code: Select all

-        while (pos != string::npos)
+        while (pos != (unsigned int)string::npos)


Note though that I'm not a programmer, so I have no way of knowing if these changes break anything else, so use them at your own risk!

That is the correct fix. I'll apply the patch for the 1.4.1 bugfix release.

By the way, see:

http://cvs.sf.net/viewcvs.py/celestia/c ... iew=markup

...and search for "actionHelpOpenGL". You'll see I made the exact same change you did in the GTK front-end.

I believe it has to do with the size of an unsigned int on 64-bit architectures.

I don't routinely test the KDE version on AMD64 (though I will start soon-ish, as it will be part of my job). I will gladly apply the patch. If you note any other strange behaviours, please make note of them. Thanks for the report!

[suwalski]

..and search for "actionHelpOpenGL". You'll see I made the exact same change you did in the GTK front-end.

I ought to read the posts more carefully next time. The source of the changes is exactly what I was then saying you should see. Oops!

The changes have been applied. If you find more, please tell.