gcompris wont start - Fatal signal: Seg. Fault [Solved]

[schiznik]

I am trying to get gcompris running, but it keeps crashing on me...

Code: Select all

acathla root # gcompris -D
** Message: gcompris_set_locale ''


** (gcompris:22616): WARNING **: Requested locale '' got 'en_GB.UTF-8'
Opened audio at 22050 Hz 16 bit mono, 512 bytes audio buffer
gcompris: Mime type mimetype=image/gcompris+anim description=GCompris animation extension=.gcanim icon=gcompris/mimetypes/icons/gcompris+anim.png
<--- snip lots of similar mime types ---> 

gcompris: We found the correct plugin for board fun (type=menu)

gcompris: Failed to open module ../boards/.libs//libmenu.so with name menu (error=../boards/.libs//libmenu.so: cannot open shared object file: No such file or directory)

gcompris: Failed to open module ./boards/.libs//libmenu.so with name menu (error=./boards/.libs//libmenu.so: cannot open shared object file: No such file or directory)

gcompris: opened module /usr/lib/gcompris/libmenu.so with name menu

gcompris: We found the correct plugin for board reading (type=menu)

gcompris: Failed to open module ../boards/.libs//libpython.so with name python (error=../boards/.libs//libpython.so: cannot open shared object file: No such file or directory)

gcompris: Failed to open module ./boards/.libs//libpython.so with name python (error=./boards/.libs//libpython.so: cannot open shared object file: No such file or directory)

gcompris: opened module /usr/lib/gcompris/libpython.so with name python

Fatal signal: Segmentation Fault (SDL Parachute Deployed)

I get this same error when running as a normal user.
Sound works in other apps, frozen-bubble & enemy territory all play ok
I presume python in general works as I can emerge stuff

Any more info needed?

[Edit - Cleaned up debug output, added solved as it mostly works now]

[charlieg]

Looks like your libs are a little cooked. Try a revdep-rebuild.

[schiznik]

hmmmm.....
Ive run revdep-rebuild 3 times now, with the same errors/messages each time.

It reinstalled oo.o 1.9 for me; and gcompris still fails with the same error....

Code: Select all

acathla@root # revdep-rebuild

Checking reverse dependencies...
Packages containing binaries and libraries broken by any package update, will be recompiled.

Collecting system binaries and libraries... done.
        (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.
        (/root/.revdep-rebuild.2_ldpath)

ldd: warning: you do not have execution permission for `/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so'
        broken /opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so (requires libBLT24.so libtk8.3.so libtcl8.3.so)
ldd: warning: you do not have execution permission for `/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/bz2.so'
        broken /opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/bz2.so (requires libbz2.so.0)
ldd: warning: you do not have execution permission for `/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/dbm.so'
        broken /opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/dbm.so (requires libgdbm.so.2)
ldd: warning: you do not have execution permission for `/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/gdbm.so'
        broken/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/gdbm.so (requires libgdbm.so.2)
ldd: warning: you do not have execution permission for '/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/mpz.so'
        broken /opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/mpz.so (requires libgmp.so.3)
ldd: warning: you do not have execution permission for `/opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so'
        broken /opt/OpenOffice.org/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so (requires libdb-3.1.so)
done.
        (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.
        (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.
        (/root/.revdep-rebuild.5_order)

All prepared. Starting rebuild...
        emerge --oneshot --nodeps =app-office/openoffice-bin-1.9.93


<snip OO.o compile>

 * GNU info directory index is up-to-date.

Build finished correctly. Removing temporary files... ..........
You can re-run revdep-rebuild to verify that all libraries and binaries are fixed. If some inconsistency remains, it can be orphaned file, deep dependency, binary package or specially evaluated library.

As a relative gentoo n00b (ive used Debian for years) how would i go about checking for the "orphaned file, deep dependency, binary package or specially evaluated library"?

I might emerge -C OO.o and rm the /opt/OpenOffice.org dir and reinstall OO.o to see if this clears the messages -^

[Calchan]

Look here:
http://forums.gentoo.org/viewtopic-t-31 ... mpris.html

Didn't have the time to really investigate this yet, but I can confirm what [Jul] says on that thread. If you compile with -python it works. It is not related to AMD64, as I get the exact same problem on Athlon XP and Pentium 4. The solution is unacceptable though, since this removes quite a number of activities in the game.

I wanted to experiment with a few things before I filed a bug, but I never went so far. I did try all available versions of python, and it didn"t work. Feel free to open one, though, and if you do so I'll provide my emerge info and such.

[RuiP]

I had this problem too.
It only disappeared after i turn back to x86 udev (i run away from ~x86 since i had a lot of problems with sound and permissions) and set my sound permision a little lighter at:
/etc/security/console.perms

Code: Select all

<console>  0666 <sound>      0666 root.audio

(instead of 0600...)
works nice now!

[schiznik]

Thanks for the info charun & ruip,

I'm using the x86 udev at the moment & I've changed the perms as you suggested, but it doesnt work as yet. I'll try rebooting to give it a fresh start when I can.

If that doesnt sort it, I'll recompile without python support & hope the games I wanted for the 2yr old are still available.

I might try the ~x86 udev and/or the sdl stuff in the thread that charun mentioned too, to see if that helps. (not sure how i missed that thread, i did search before i posted initially.)

[Calchan]

I'm using the x86 udev at the moment & I've changed the perms as you suggested, but it doesnt work as yet. I'll try rebooting to give it a fresh start when I can.

I'm using ~x86 everything, and it doesn't work either. I changed the permissions and rebooted, same thing.

I might try the ~x86 udev and/or the sdl stuff in the thread that charun mentioned too, to see if that helps. (not sure how i missed that thread, i did search before i posted initially.)

I seem to remember that I tried all sdl versions and that it didn't help either. Not 100% sure though, as this was a couple of weeks ago.

[RuiP]

I'm using the x86 udev at the moment & I've changed the perms as you suggested, but it doesnt work as yet. I'll try rebooting to give it a fresh start when I can.
If that doesnt sort it, I'll recompile without python support & hope the games I wanted for the 2yr old are still available.

sorry that don't work!

I forget to ask, does gcompris works if it was launched as root?

I hardly believe that python as any problem... and i compiled all versions of sdl available, with no luck.

I had lot of problems with gcompris, tuxpaint and childsplay (my kid almost started to hate gentoo!)
I had a plain stage 1, x86, of the old 2004.2 version. (I still have that version on disk and still have problems...)
But all problems had gone away since i done a new stage 1 on stage 3 install (+ that perimission change i mention).
I don't think it was just that by magic, but my theory is that what make it work was the compilation of system with the
gcc 3.4.3.20050210-r1+glibc 2.3.4.20050125-r1 (both ~x86)! If anything fails and you don't had that versions you may want to try to recompile
your toolkit and system and check if does any good (in any case should give you some speed boost... or at least some people claim that).

Anyway, with the problematic version i used 2 tricks you may want ot try.
One was launch esd first and then gcompris (or childsplay). Make it work 40% of the times i tried.
The other was just download the code and compiled direct (.config, make, make install). I remember it work at least for one of childsplay/gcompris... i don't remember exactly wich one...

[schiznik]

Well, firstly sorry for the delay, secondly its working finally.

Ive compiled gcompris with -python. It actually runs as a user now, but crashes eventually when trying to play some of the music eg:

Code: Select all

-rw-r--r--  1 root root 2.2M Apr 23 23:09 /usr/share/gcompris/boards/music/background/BarDasImagens.ogg

These play fine as root, and so does gcompris now.

It cant be the ~x86 toolchain causing the problem - it was the first thing i did after installing this box (technically i did a stage 1 on 3).

I believe that recompiling with -python fixed the problem, however I cant spot whats missing due to the lack of python.

I think i might put a [SOLVED] on the title, as its working, albeit as root.

I think gcompris probably needs a bug of some kind filed against it, however I;

• a) am not sure how to, and
  b) as my system is a -nitro kernel, with a nice mix of ~x86 and x86, and originally a vidalinux install, before i recompiled everything with my -O3 etc CFLAGS, I dont think the devs would accept bugs from me without me making another install with more 'default' settings.

(Edit: removed too much blank space....)

[RuiP]

hi,
if sound works as root, is not a gcompris problem, but a permissions problem.
If my sugestion for changing the permissions at console.perms didn't work, probabily its necessary to change some udev rule
(a little annoying to do by hand, anyway).

In order to post a bug you need to register in bugzilla and get a password (like you do in forums), only that.
But this is not a gcompris bug (in my case after i install a clean system all problems with sound+gcompris disapeared...)
And you are right with your system specifications any dev will freak out... If i get it right, you install a vidalinux (stage 3), then moved to a stage 1, mixing x86 and ~x86 and agressive CFLAG. You are an experimentalist You asked for problems


If gentoo didn't take so long to install i would sugest a fresh (and more relaxed one) install side by side your experimental one...

Anyway the -python flag should only eliminate some of the "activities" of gcompris, it's not a fundamental piece, i guess.

about sound problems as a normal user, do you tried

Code: Select all

esd && gcompris

When i had that problem, sometimes (not always) worked.

[schiznik]

Starting the esound daemon works, im recompiling with python support at the moment to see if it still crashes with permission problems. If it works with python support, would it be possible that gcompris needs an esd USE flags or something?

You're right about my system (except you missed the unsupported kernel ) Maybe If I can find the time, inclination and hard drive space I'll do a regular, sane, x86 install, but as everything else is working ok I doubt it'll happen soon... unless I break it somehow..........

Compile done...
Nah, it still crashes, time to recompile it again....

Well at least most of it mostly works , thanks for the time/assistance.

[Calchan]

I still get the problem (root or not), and that's on two clean gentoo machines, one Pentium 4 and one Athlon XP. Both are stage 1 ~x86 systems (the Pentium 4 had a full reinstall less than a month ago) and are very regularly maintained with a systematic revdep-rebuild after each emerge update. I have tried all versions of gcompris from 6.1 to 6.5.3 and they all do the same. The annoying thing is that until a couple of months ago, I had no problem with all available versions (up to 6.4 at that time I think), which tends to indicate it's not a problem with gcompris itself.

Here's a copy of what gdb tells me, for those who are interested:

Code: Select all

[...]
[Thread debugging using libthread_db enabled]
[New Thread -1219639040 (LWP 19268)]
** Message: gcompris_set_locale 'fr_FR.UTF-8'

[New Thread -1221149776 (LWP 19271)]
Opened audio at 44100 Hz 16 bit stereo, 2048 bytes audio buffer
[New Thread -1229755472 (LWP 19272)]
[New Thread -1238148176 (LWP 19273)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219639040 (LWP 19268)]
0xb56f254c in init_gtk () from /usr/lib/python2.3/site-packages/gtk-2.0/gtk/_gtk.so

I hope I have some time soon to investigate this further.

[greedy]

Had this same problem with my install, although not gentoo (slackware)

I had to download python-gtk from http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.4/

./configure --prefix=/usr && make && make install

and then gcompris worked.


- Daniel

[Calchan]

Thanks a lot greedy. I just masked pygtk-2.6.0 and pygtk-2.6.1, re-emerged gcompris without -python and it works. So the issue appears to be in gcompris which does not seem to support pygtk-2.6.0 and higher. I'll try and report it upstream.

For those interested, while trying to solve this I made ebuilds of gcompris up to 6.5.3 by just copying and renaming the 6.5 ebuild into my portage overlay. Not only does version 6.5.3 work great and fix some bugs, but it contains lots of polishing. Try it.

[RuiP]

Hi,
as i said before, i had gcompris on 2 gentoos; one is a stage 1, devfs, x86 and the other is a stage 1on3, udev, x86.
It works fine on the last but had this problem on the first.

On *both* cases they are compiled with pygtk 2.4.1 and with "python" (not -python ) as a USE flag.

Besides that, with the first system i had the same problem at least with childsplay, tuxtype, tuxpaint and kaffeine...
So I think the problem is not specific to gcompris nor to pygtk-2.6 (it can happens too with 2.4).

Another strange aspect is that i (and schiznik too) can make the thing work launching first esd... so is not broken in fact.
Those apps don't start because they seem to need a sound deamon to work (or they seg fault...) and it was none available or they cannot make the daemon starts (and work).
I tend to think that problem was more on sound, an alsa, oss, esd (or arts) problem or something that should connect to one of them and won't... In fact there's a lot of threads on similar problems (sound stuff and segment faults) on this forums for a lot of other applications, like frozen-boble and other games. Alsa seems to give, sometimes, a lot of problems...

On the other subject: Thanks for the tip for the ebuilds! (Childs stuff seems to go slowly on gentoo...)
Do you find news enough on 6.5.3 to recomend a try? I've became a little afraid that it will mess the now working 6.5

[Calchan]

Another strange aspect is that i (and schiznik too) can make the thing work launching first esd... so is not broken in fact.
Those apps don't start because they seem to need a sound deamon to work (or they seg fault...) and it was none available or they cannot make the daemon starts (and work).
I tend to think that problem was more on sound, an alsa, oss, esd (or arts) problem or something that should connect to one of them and won't... In fact there's a lot of threads on similar problems (sound stuff and segment faults) on this forums for a lot of other applications, like frozen-boble and other games. Alsa seems to give, sometimes, a lot of problems...

Are you running Gnome as a window manager ? If so, have you tried going into your desktop preferences menu, and clicked on 'multimedia systems selector'. There, select either alsa or OSS as your sink (output) and source (input) pipes. Anything but ESD actually, and don't start ESD or kill it if it's started manually.

Do you find news enough on 6.5.3 to recomend a try? I've became a little afraid that it will mess the now working 6.5

Definitely. There's nothing new in the code apart from bugfixes, so no reason to be afraid, but there's lots of polishing in the data (audio, images, icons). Try it !

[RuiP]

Hi Charun,
maybe i'm not explainning myself right... My gcompris works 100% fine, no problem at all.
It was an old instalation that give me problems!

My point was only that i don't see how can this be a python problem, since i had 1 working and 1 non-working gcompris, *both* with USE=python and *both* with pygtk-2.4...
And, it's not a gcompris specific problem too, since the some happens with others apps (tuxtype, childsplay, frozen-bubble, tuxpaint, kaffeine at least). They all seg fault and all complain about sound or break when they try to start something related to sound.

I know it was not supposed to manually start esd! (the final d on esd is for daemon...)
That's the problem! daemon did not start (or starts wrong and crash).
My "manual" esd start suggestion was just a dirty workaround...
And btw, i've got the same problem with xfce4, fluxbox, kde and gnome (tried with all). On gnome same happen with and without sound server startup enabled...

I will tried the 6.5.3 (on my normal and working version) soon as i've got a little free time, maybe next weekend... thanks for the suggestion.

[Calchan]

My point was only that i don't see how can this be a python problem, since i had 1 working and 1 non-working gcompris, *both* with USE=python and *both* with pygtk-2.4...
And, it's not a gcompris specific problem too, since the some happens with others apps (tuxtype, childsplay, frozen-bubble, tuxpaint, kaffeine at least). They all seg fault and all complain about sound or break when they try to start something related to sound.

That's why I'm suggesting you check this, if you haven't already :

have you tried going into your desktop preferences menu, and clicked on 'multimedia systems selector'. There, select either alsa or OSS as your sink (output) and source (input) pipes.