From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: When running Celestia as a normal user, It crashes after showing "nStarts: XXXXXX", with a SIGSEGV signal. Version-Release number of selected component (if applicable): celestia-1.3.2-2 How reproducible: Always Steps to Reproduce: 1.Install Celestia from Fedora-extras (I had previously compiled binaries deleted) 2.Launch It. Actual Results: Celestia tells "nStars: 112524", inmediately after it shows the Gnome Crash Dialog. A strace tells me it is a "SIGSEGV (Segmentation fault) ", but nothing seems out of order there. You can have a look at attached file. Expected Results: Celestia should have runned as normal Additional info: Strace Extracts: Long Befora Crash, when the last Celestia config file is loaded and it starts to load GTK: open("guide.cel", O_RDONLY|O_LARGEFILE) = 16 read(16, "{\n\tName \"Jupiter\"\n\tTarget \"Sol"..., 8191) = 3724 read(16, "", 8191) = 0 close(16) = 0 open("/usr/share/locale/es_ES.UTF-8/LC_MESSAGES/libgnomeui-2.0.mo", O_RDONLY) = -1 ENOENT (No such file or directory) (I assume this last line is normal.) Just Before Crash: read(13, "GIOP\1\2\1\0013\0\0\0", 12) = 12 read(13, "\300\224\354\376\0\0\0\0\1\0\0\0\1\0\0\0\f\0\0\0\1\1\1"..., 51) = 51 writev(13, [{"GIOP\1\2\1\0\231\0\0\0", 12}, {"\300\224\354\376\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0~\206"..., 153}], 2) = 165 poll([{fd=6, events=POLLIN}, {fd=13, events=POLLIN|POLLPRI, revents=POLLIN}, {fd=14, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}], 4, -1) = 1 read(13, "GIOP\1\2\1\0013\0\0\0", 12) = 12 read(13, "\300\224\354\376\0\0\0\0\1\0\0\0\1\0\0\0\f\0\0\0\1\1\1"..., 51) = 51 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Created attachment 108851 [details] This is the whole Strace Log. This is the full Strace log (strace celestia). 'Uname -a' is "Linux pcjavier 2.6.9-1.681_FC3 #1 Thu Nov 18 15:10:10 EST 2004 i686 athlon i386 GNU/Linux"
1) What do you get for...? $ ls -lR /etc/gconf | grep celestia 2) To save time, please "rpm -e celestia ; yum -y install celestia". Does that change anything?
Output of "ls -lR /etc/gconf | grep celestia" -rw-r--r-- 1 root root 13982 mar 15 2004 celestia.schemas The file seems complete (ends with </gconfschemafile>). Reinstalling didn't do any good, same behaviour. I forgot to say, it runs perfectly as root. I'm using binary nvidia drivers.
Wait! After reinstall, I run it as root (went perfectly), run it as user (failed). I tested it many times, including between some logons on the system. But after a reboot, just clicked on the menu item and it started working!!. I'll try if reinstalling now will make it fail again.
Re: comment 3 No, that's not enough. And it backs up my theory. You should see many more files as created by the celestia post-install script (viewable with rpm --query --scripts celestia). For some unknown reason, the script was not executed when you installed celestia. I was able to reproduce it the first time I ran "yum -y install celestia" to fetch it from pre-Extras. Used the chance to create a backtrace, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151136576 (LWP 20077)] 0x080a44a4 in readGConfMain (p=0xfef1a9b0) at char_traits.h:258 258 { return strlen(__s); } (gdb) bt #0 0x080a44a4 in readGConfMain (p=0xfef1a9b0) at char_traits.h:258 #1 0x080a455e in loadSavedPreferences (p=0xfef1a9b0) at gtkmain.cpp:3949 #2 0x080a49db in main (argc=1, argv=0xfef1aaa4) at gtkmain.cpp:4214 which in turn lead to noticing that the GConf defaults were missing. Went and tested installating the package manually with "rpm -ivvh", and I'm no longer able to reproduce it.
You're right, now that it is working always I have lots of files more in gconf/schemas. (So it started working on allusers due to reboot of gconfd) And I'm not able to reproduce it again. However, I remember something similar also happened when compiling from source, while ago. So, I assume the same same script is run on RPM post-install and 'make install'. It's strange it happens only when you're installing for first time a new version of Celestia. Could it be a problem while deleting old schema files?
This does definitely sound like GConf defaults were missing. Unfortunately, I can't look into it right now, as I won't have access to any Linux system before Christmas day.
It is strange, today I reinstalled FC3 (format of / included) and tried to install celestia. Crashed as user, but then I launched gnome-terminal, su root, and typed in 'celestia'... it worked :S. Then I logged out, logged in as normal user to gnome, and it works always, for all users of my system. Can't make it fail again.... This is the whole schema list, isn't ? drwxr-xr-x 5 root root 4096 ene 2 18:17 celestia /etc/gconf/gconf.xml.defaults/apps/celestia: /etc/gconf/gconf.xml.defaults/apps/celestia/labels: /etc/gconf/gconf.xml.defaults/apps/celestia/orbits: /etc/gconf/gconf.xml.defaults/apps/celestia/render: drwxr-xr-x 5 root root 4096 ene 2 18:17 celestia /etc/gconf/gconf.xml.defaults/schemas/apps/celestia: /etc/gconf/gconf.xml.defaults/schemas/apps/celestia/labels: /etc/gconf/gconf.xml.defaults/schemas/apps/celestia/orbits: /etc/gconf/gconf.xml.defaults/schemas/apps/celestia/render: -rw-r--r-- 1 root root 13982 mar 15 2004 celestia.schemas
I had this issue, too. Attached is a small set of replacement/additional files for the celestia-1.3.2-2 source RPM. The alteration (a new celestia.spec and associated patch file) allows Celestia to run on my system. I believe this behavior is caused by one of two instances in the source code where the return value of gconf_client_get_string is blindly assigned to a std::string object. Apparently, gconf_client_get_string is allowed to return a NULL value, and when it does, the string code immediately calls strlen (thus, crashing). The alteration will check the return values acquired from gconf_client_get_string and assign "" to the string if the return value is NULL.
Created attachment 117107 [details] Slight alteration to avoid null pointer access Here's the attachment
I take it back. The patch I included, in conjunction with the effect you described wherein no gconf parameters were installed, is what caused another problem I was having: nothing was showing up in the window. Apparently, those configuration parameters are kinda important (who knew?). Anyhow, running the program once as root successfully wrote the default parameters out, and it works for normal users from there on out.
Let me kindly point to comment 5. Actually, the interesting issue with this bug is that the package's post-install scriptlet should install the gconf defaults. Under unknown circumstances it fails to do that, which is not always reproducible. Trying to work around undefined values in the application would be added run-time safety, but still only a work-around.
So, what's the final solution? This still happens on FC4
Mostafa Afgani, please read through the previous comments. *If* GConf defaults are missing for unknown reasons, that is not a packaging fault, because the package does install the files in its scriptlets. *If* the defaults are installed and Celestia crashes nevertheless, it is an application bug which can only be tracked down with a complete backtrace.
Just installed celestia from extras on fc4, crashed on startup after having printed nstars: (plus the dual menu entry bug). I have never before installed celestia on this machine. Version: celestia-1.3.2-3 Only strange thing i can see (don't know if its wrong) is that buildhost is extras64 - and i'm running on a pentium3-mobility
I am the upstream maintainer for this schema. It's a known issue, and, when installed from source, seems to be based on automake not generating a proper gconf install block. But I would think that the RPM would run a schema install script in and of itself, regardless of what 'make install' does, no?
The rpm package just uses the /etc/gconf/schemas/celestia.schemas file that got installed by "make install", so if it's not correct, then it definitely would explain the problem. Could you maybe provide a workaround? Could a working .schemas file be used to overwrite the broken one right after "make install"? I just ran into this problem on a clean FC4 system, so I can confirm it is still there.
Okay, so the schema is there. But that's not the important part. Can you verify that the directory tree: /etc/gconf/gconf.xml.defaults/schemas/apps/celestia exists and is populated? Celestia 1.3.2 has a bug that it crashes when there aren't defaults. It's a simple omission on my part, and it's fixed in my development tree for 1.4.0 (which, btw, is largely rewritten in terms of the GTK/Gnome UI). The Makefile brokenness seems limited to where the schema goes. The Ubuntu packager notes this in his debian/rules file: # That's because the Makefile is not properly working rm $(CURDIR)/debian/celestia-common/celestia.schemas rm $(CURDIR)/debian/celestia/celestia.schemas rm $(CURDIR)/debian/celestia-glut/celestia.schemas Turns out it only has to do with the schemas file being installed when it should not be (glut, kde, gtk). So that's not the problem. What the RPM probably needs is something like Debian's "dh_gconf", which puts the following into the postinst file: GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` \ gconftool-2 \ --makefile-install-rule $SCHEMA_LOCATION/$SCHEMA On a broken system, can someone verify that just running that on the celestia.schema file solves the issue?
Celestia-1.4.0 was released today. It probably solves the issue.
Apparently updating to 1.4.0 isn't an option for FC3: Requested 'gtk+-2.0 >= 2.6' but version of GTK+ is 2.4.14 configure: error: Package requirements (libgnomeui-2.0 gtk+-2.0 >= 2.6 gtkglext-1.0) were not met. Do FC4/FC5 need the gconftool-2 command added to %post?
I can not reproduce this bug in celestia-1.4.1-7.fc7 from Fedora 8. Fedora project no longer maintains Fedora Core 3. If you can reproduce this bug in Fedora 7 or 8 please reopen.
Also, celestia-1.5.0 recently came out.