FIFE forums

General Category => Help and troubleshooting => Topic started by: ape on December 05, 2007, 08:25:26 am

Title: Segfault in __cxa_allocate_exception
Post by: ape on December 05, 2007, 08:25:26 am
EDIT2 by mvbarracuda:
There is a workaround in SVN now! Try it out and let us know if it works.

======================================================

I had tried to run techdemo.py, but i got a segmentation fault.

backtrace: http://nopaste.biz/22035 (http://nopaste.biz/22035)

I have build it with scons ext=1 ...

EDIT by mvBarracuda:
Here is the full build log as pasted text tends to expire rather fast:
Code: [Select]
#0  0x00002b4d9b0a7b9d in __cxa_allocate_exception ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/libstdc++.so.6
#1  0x00002b4d991be622 in FIFE::SubImageProvider::createResource (this=0x9fd910, location=@0x10cc4a0)
    at engine/core/loaders/native/video_loaders/subimage_provider.cpp:52
#2  0x00002b4d991db25c in FIFE::Pool::findAndSetProvider (this=0x9ffc90, entry=@0x10cc420)
    at engine/core/util/resource/pool.cpp:167
#3  0x00002b4d991db76d in FIFE::Pool::get (this=0x9ffc90, index=19)
    at engine/core/util/resource/pool.cpp:105
#4  0x00002b4d99193466 in FIFE::ImagePool::getImage (this=0x9ffc90, index=19)
    at engine/core/video/imagepool.h:54
#5  0x00002b4d992300cd in _wrap_ImagePool_getImage (args=0xa72b00)
    at engine/swigwrappers/python/fife_wrap.cxx:75408
#6  0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#7  0x00002b4d9810445d in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#8  0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#9  0x00002b4d98104aa5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#10 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#11 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#12 0x00002b4d980b5676 in ?? () from /usr/lib/libpython2.5.so.1.0
#13 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#14 0x00002b4d980a19b4 in ?? () from /usr/lib/libpython2.5.so.1.0
#15 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#16 0x00002b4d98100a7f in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.5.so.1.0
#17 0x00002aaab5a01c68 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#18 0x00002aaab5a038af in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#19 0x00002aaab5a0b551 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#20 0x00002aaab5a0c3f8 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#21 0x00002aaab5a0d93c in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#22 0x00002aaab5a0e45d in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#23 0x00002aaab5a059fc in XML_ParseBuffer ()
   from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#24 0x00002aaab5a04d31 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#25 0x00002b4d981062a7 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#26 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#27 0x00002b4d98104aa5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#28 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#29 0x00002b4d980b5676 in ?? () from /usr/lib/libpython2.5.so.1.0
#30 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#31 0x00002b4d980a19b4 in ?? () from /usr/lib/libpython2.5.so.1.0
#32 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#33 0x00002b4d9810387c in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#34 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#35 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#36 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#37 0x00002b4d980b5676 in ?? () from /usr/lib/libpython2.5.so.1.0
#38 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#39 0x00002b4d980a19b4 in ?? () from /usr/lib/libpython2.5.so.1.0
#40 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#41 0x00002b4d98100a7f in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.5.so.1.0
#42 0x00002aaab5a01c68 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#43 0x00002aaab5a038af in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#44 0x00002aaab5a0b551 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#45 0x00002aaab5a0c3f8 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#46 0x00002aaab5a0d93c in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#47 0x00002aaab5a0e45d in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#48 0x00002aaab5a059fc in XML_ParseBuffer ()
   from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#49 0x00002aaab5a04d31 in ?? () from /usr/lib64/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
#50 0x00002b4d981062a7 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#51 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#52 0x00002b4d98104aa5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#53 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#54 0x00002b4d980b5676 in ?? () from /usr/lib/libpython2.5.so.1.0
#55 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#56 0x00002b4d980a19b4 in ?? () from /usr/lib/libpython2.5.so.1.0
#57 0x00002b4d9809bc1f in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#58 0x00002b4d9810387c in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#59 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#60 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#61 0x00002b4d98105dee in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#62 0x00002b4d98106bbb in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#63 0x00002b4d98106c6d in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#64 0x00002b4d9811e60a in ?? () from /usr/lib/libpython2.5.so.1.0
#65 0x00002b4d9811e6ba in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
#66 0x00002b4d9811f9fe in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
#67 0x00002b4d98127eb0 in Py_Main () from /usr/lib/libpython2.5.so.1.0
#68 0x00002b4d98c6cb74 in __libc_start_main () from /lib/libc.so.6
#69 0x00000000004006e9 in _start ()
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: chewie on December 05, 2007, 09:13:08 am
@ape

Did you

Code: [Select]
scons ext=1 && scons

? Scons ext=1 alone won't do the trick ;-)
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: mvBarracuda on December 05, 2007, 09:25:23 am
Yep he did :-) he was on the channel some hours ago and ran both commands but forgot to mention that in his posting.
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: anxs on December 05, 2007, 12:10:59 pm
I guess it has either to do with the version of the gcc-libraries (4.2.2 is the newest one, I myself use 4.2.1) or with the 64bit environment...
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: skybound on December 06, 2007, 09:11:57 am
This seems like a hard to find bug...

ape: Does "cd tests/core_tests ; ./testprog_imagepool" work?

I assume you started from a clean checkout (so that there may be no old compiled object files, maybe when you where using an older compiler)? In theory scons should avoid this problem, but better sure than hunting forever; a compiler mismatch seems a plausible cause.

Btw: you _are_ using gcc 4.2.2 right? If you have multiple compilers installed be sure that the libstdc++ matches the compiler.

The fact that is segfaults while trying to throw an exception is strange; unless someone has a bright idea I suggest to open a trac ticket so that more information on this problem can be pooled. Sooner or later someone else on amd64 and/or this compiler might run into this.
For the moment I don't see enough information to even make a guess.
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: mvBarracuda on February 10, 2008, 11:42:11 am
This problem showed up for somebody else now:
http://mirror1.cvsdude.com/trac/fife/engine/ticket/297

Similarities to the original poster: 64bit linux, gcc 4.2.x.
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: mvBarracuda on March 12, 2008, 06:29:39 pm
Nihathrael from OpenAnno just pointed me to this thread:
http://www.dangerdeep.net/forums/viewtopic.php?t=246&postdays=0&postorder=asc&start=19

Looks like the issue is related to ATI's 64bit driver. A workaround seems possible but complicated. I just posted it hoping that some clever programmer would be able to use this kind of information :-)
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: Joshdan on March 12, 2008, 10:30:03 pm
The stack trace indicates the issue was in libstdc++.so.6, and doesn't seem to include any GL or SDL anything, so I don't think it has to do with ATI.  I'd guess it has something to do with pointers judging from the lines of subimage_provider affected.
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: skybound on March 13, 2008, 12:53:00 pm
Nihathrael from OpenAnno just pointed me to this thread:
http://www.dangerdeep.net/forums/viewtopic.php?t=246&postdays=0&postorder=asc&start=19

Looks like the issue is related to ATI's 64bit driver. A workaround seems possible but complicated. I just posted it hoping that some clever programmer would be able to use this kind of information :-)

I don't see the connection; what has the dangerdeep post (missing GL symbols at compile time) got to do with our crash?

Quote from: Joshdan
The stack trace indicates the issue was in libstdc++.so.6, and doesn't seem to include any GL or SDL anything, so I don't think it has to do with ATI.  I'd guess it has something to do with pointers judging from the lines of subimage_provider affected.

I agree that it doesn't appear to be related to GL at first glance; we have a second trace http://mirror1.cvsdude.com/trac/fife/engine/attachment/ticket/297/bt.2.log which is possibly as far from GL as possible, though it appears to be the same problem.

Both people report that the problem does not occur when disabling the GL backend.
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: mvBarracuda on March 13, 2008, 01:00:04 pm
I don't see the connection; what has the dangerdeep post (missing GL symbols at compile time) got to do with our crash?
I was not totally sure either but I thought that it would be a good idea to post it nevertheless. I blame Nihathrael from OpenAnno for convincing me to do so :-p
Title: Segfault with latest SVN; Ubuntu 7.10
Post by: nouri on March 13, 2008, 06:30:27 pm
I have successfully built the fife engine from latest SVN.  I've also tried the FIFE_2008.0_r2109_src release with the same results.  I'm using glibc 2.6.1, and I'm on Ubuntu 7.10.

This is the last part of my stack trace:

Code: [Select]
==23599==    by 0x4A146B8: FIFE::Pool::get(unsigned, bool) (pool.cpp:103)
==23599==    by 0x49BC3EE: FIFE::ImagePool::getImage(unsigned) (imagepool.h:54)
==23599==    by 0x4ABDB15: _wrap_ImagePool_getImage (fife_wrap.cxx:84751)
==23599==    by 0x805C786: PyObject_Call (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C6C2E: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C9CA4: PyEval_EvalCodeEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8168: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8EA4: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8EA4: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==23599==
==23599== Process terminating with default action of signal 11 (SIGSEGV)
==23599==  Access not within mapped region at address 0x4
==23599==    at 0x5282096: __cxa_allocate_exception (in /usr/lib/libstdc++.so.6.0.9)
==23599==    by 0x49E6D92: FIFE::SubImageLoader::loadResource(FIFE::ResourceLocation const&) (subimage_loader.cpp:49)
==23599==    by 0x4A13E7A: FIFE::Pool::findAndSetProvider(FIFE::Pool::PoolEntry&) (pool.cpp:204)
==23599==    by 0x4A146B8: FIFE::Pool::get(unsigned, bool) (pool.cpp:103)
==23599==    by 0x49BC3EE: FIFE::ImagePool::getImage(unsigned) (imagepool.h:54)
==23599==    by 0x4ABDB15: _wrap_ImagePool_getImage (fife_wrap.cxx:84751)
==23599==    by 0x805C786: PyObject_Call (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C6C2E: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C9CA4: PyEval_EvalCodeEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8168: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8EA4: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==    by 0x80C8EA4: PyEval_EvalFrameEx (in /home/daniel/devel/virtualenv/bin/python)
==23599==

Does this ring a bell?  Am I using an incompatible version of some library?  Anything else that I could check?
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: jasoka on March 14, 2008, 07:03:06 pm
looks like there's similar case: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364907

From post:
this behaviour does not occur, when i have version(4.0.2-9) installed on my system.
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: Sleek on March 14, 2008, 07:50:46 pm
For anyone having this problem, please do a

Code: [Select]
gcc --version

and post your result here. Thanks.
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: nouri on March 15, 2008, 06:35:50 am
Code: [Select]
daniel@redhotcar:~$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: Sleek on March 15, 2008, 08:14:53 am
Would appreciate if you could test the attached binary below. If this doesn't run for you I'll give the source to you to compile there.

http://members.fifengine.net/sleek/fifetester (http://members.fifengine.net/sleek/fifetester)

How to run it:
Code: [Select]

1 - Place fifetester anywhere
2 - cd to island_demo where run_demo.py resides
3 -
path_to_this_binary/fifetester run_demo.py
 _or_
gdb --args fifetester run_demo.py
 _or_
valgrind fifetester run_demo.py

I would very much appreciate if you could paste results from all the above below. The island will not look right. Everything will be drawn at one location, don't worry about this. When you use gdb, when it segfaults, enter 'where' ( in gdb console ) to show the stacktrace. Thanks.

New binary (1). The search path for libfife.so is ../../engine/libfife.so. Make sure you execute fifetester from within island_demo directory. Also check that you have libfife.so under trunk/engine/. If not, copy _fife.so from trunk/engine/swigwrappers/python.
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: nouri on March 15, 2008, 08:54:02 am
Sleek,

I'm afraid this didn't work out.  The binary contained a reference to ./engine/swigwrappers/python/_fife.so on your system, which resulted in:

Code: [Select]
/home/daniel/tmp/fifetester: error while loading shared libraries: /home/sleek/FIFEsvn/trunk/engine/swigwrappers/python/_fife.so:
cannot open shared object file: No such file or directory

I tried to replace this string with the correct path on my system, but then got a segfault for the demo.

With gdb I get:

Code: [Select]
daniel@redhotcar:~/co/cvsdude/fife-engine/clients/island_demo$ gdb --args ~/tmp/fifetester run_demo.py
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
"/home/daniel/tmp/fifetester": not in executable format: File format not recognized

Trying the equivalent with valgrind, I get a segfault without any further information.

One more thing, when I try to gdb --args the run_demo.py (which I tried and made executable), i"m getting this.  What am I doing wrong:

Code: [Select]
"/home/daniel/co/cvsdude/fife-engine/clients/island_demo/run_demo.py": not in executable format: File format not recognized
Title: Segmentation Fault with enabled OpenGL - ArchLinux 64bit
Post by: Nihathrael on March 15, 2008, 09:35:43 am
Hi all, i get a Segmentation Fault when running any FIFE client.

OS: ArchLinux - x86_64
GCC: 4.2.3
FIFE Version: SVN revision 2318

Backtrace:
Code: [Select]
(gdb) bt
#0  0x00002ae3cf354e05 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x00002ae3cd560407 in FIFE::MetaModel::createDataset (this=0x19396f0, identifier=@0x1a903b0) at engine/core/model/metamodel/metamodel.cpp:54
#2  0x00002ae3cd6b653b in _wrap_MetaModel_createDataset (args=0x9d6cb0) at engine/swigwrappers/python/fife_wrap.cxx:57413
#3  0x00002ae3cb8e60d3 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#4  0x00002ae3cb963275 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#5  0x00002ae3cb9661f6 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#6  0x00002ae3cb964247 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#7  0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#8  0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#9  0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#10 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#11 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#12 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#13 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#14 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#15 0x00002ae3cb9661f6 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#16 0x00002ae3cb964247 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#17 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#18 0x00002ae3cb9661f6 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#19 0x00002ae3cb906b08 in function_call () from /usr/lib/libpython2.5.so.1.0
#20 0x00002ae3cb8e60d3 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#21 0x00002ae3cb8ed7b5 in instancemethod_call () from /usr/lib/libpython2.5.so.1.0
#22 0x00002ae3cb8e60d3 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#23 0x00002ae3cb92ed2c in slot_tp_init () from /usr/lib/libpython2.5.so.1.0
#24 0x00002ae3cb92e0d8 in type_call () from /usr/lib/libpython2.5.so.1.0
#25 0x00002ae3cb8e60d3 in PyObject_Call () from /usr/lib/libpython2.5.so.1.0
#26 0x00002ae3cb962320 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#27 0x00002ae3cb965003 in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0
#28 0x00002ae3cb9661f6 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0
#29 0x00002ae3cb966312 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0
#30 0x00002ae3cb988e91 in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0
#31 0x00002ae3cb98912b in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0
#32 0x00002ae3cb991eea in Py_Main () from /usr/lib/libpython2.5.so.1.0
#33 0x00002ae3cc4d8164 in __libc_start_main () from /lib/libc.so.6
#34 0x0000000000400679 in _start ()

I hope this is of any help.

So long
Nihathrael
Title: Re: Segfault with latest SVN; Ubuntu 7.10
Post by: nouri on March 15, 2008, 09:58:38 am
I just tried gcc 4.2, but that didn't help.
Title: Segmentation fault
Post by: gvv.coder on May 16, 2008, 11:38:56 am
I have too many sex with libraries  :)
Now i compile engine, but have some troubles

Some information of my system:
Code: [Select]
GCC: 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Distro: Ubuntu 8.04
Python: 2.5.2
SWIG: 1.3.33
FIFE: not svn-version. Default from Downloads
Arch: i686
Scons: v0.97.0d20071203.r2509
MiniZip: 1.01b
When i run test_fife.py i get error's in some tests.

9:
Code: [Select]
-> : 9
testFonts (tests.swig_tests.gui_tests.TestGui) ... Segmentation fault

10:
Code: [Select]
-> : 10
testDrawLine (tests.swig_tests.video_tests.TestVideo) ... ok
testSimpleAnimation (tests.swig_tests.video_tests.TestVideo) ... Segmentation fault

12:
Code: [Select]
-> : 12
testAnimationPool (tests.swig_tests.resource_tests.TestPool) ... Segmentation fault

13:
Code: [Select]
-> : 13
testDatasets (tests.swig_tests.model_tests.TestModel) ... ok
testElevations (tests.swig_tests.model_tests.TestModel) ... ok
testLayers (tests.swig_tests.model_tests.TestModel) ... 4 4
4 4
ok
testMaps (tests.swig_tests.model_tests.TestModel) ... ok
testMetaModel (tests.swig_tests.model_tests.TestModel) ... ok
testModel (tests.swig_tests.model_tests.TestModel) ... ok
testRunAngle0 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle134 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle135 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle136 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle269 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle270 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle271 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle314 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle359 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle40 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle400 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle45 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle451 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle89 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle90 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testRunAngle91 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testWalkAngle0 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testWalkAngle199 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testWalkAngle60 (tests.swig_tests.model_tests.TestActionAngles) ... ok
testDiagSquareGrid (tests.swig_tests.model_tests.GridTests) ... (0, 1) True
(1, 2) True
(0, 0) True
(2, 1) True
(1, 1) True
(2, 0) True
(2, 2) True
(1, 0) True
(0, 2) True
Segmentation fault

16:
Code: [Select]
-> : 16
testWalkAround (tests.swig_tests.action_tests.ActionTests) ... Segmentation fault

19:
Code: [Select]
-> : 19
testCamera (tests.swig_tests.view_tests.TestView) ... Segmentation fault

Other tests runs normaly. Where mistake?

PS: Sorry for my bad english, and, please correct me, if i write not correctly(i what to learn)
Title: Re: Segmentation fault
Post by: mvBarracuda on May 17, 2008, 12:04:22 pm
Please provide a gdb backtrace and try the latest trunk instead of the 2008.0 release:
http://wiki.fifengine.net/Debugging#Linux
Title: Re: techdemo.py trunk (2007.3) segmentation fault amd64
Post by: Sleek on July 16, 2008, 04:15:50 am
Some bug reports on the same problem:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364907

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365245


Please download this file  (http://mirror1.cvsdude.com/trac/fife/engine/attachment/ticket/297/Exception_tests.4.zip) and give it a test. Read the instruction first !

There are two tests : basicexception and exceptionwithopengl. Run any of them in a console, and please tell the result here. If there is any crashes, include the backtrace. Also, please put down your system's spec, graphic card type, graphic card driver and libstdc++ version. Thanks.


Updated ! There is a new test, simple OpenGL + swig + python in the form of run.py. Execute test_exception.py from FIFE root folder or execute from within tests/exception_tests/.
Title: Re: Segmentation fault
Post by: ChickenGrope on July 20, 2008, 02:52:16 pm
Bug seconded.  At this point I wish I was better at finding segfaults...

Some info:
Quote
Distro: Ubuntu 8.04 (x86_64)
GCC: 4.2.3
Python: 2.5.2
Swig: 1.3.33

I'll use test 12 as my example.  Running:

Quote
warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 0000000000000120
testAnimationPool (tests.swig_tests.resource_tests.TestPool) ... [New Thread 0x415c9950 (LWP 13196)]
[Thread 0x415c9950 (LWP 13196) exited]
ok
testAnimationPoolFail (tests.swig_tests.resource_tests.TestPool) ... [New Thread 0x415c9950 (LWP 13197)]
[Thread 0x415c9950 (LWP 13197) exited]
ok
testImagePool (tests.swig_tests.resource_tests.TestPool) ... [New Thread 0x415c9950 (LWP 13198)]
[Thread 0x415c9950 (LWP 13198) exited]
ok
testImagePoolFail (tests.swig_tests.resource_tests.TestPool) ... [New Thread 0x415c9950 (LWP 13200)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f06d7b6a6e0 (LWP 13193)]
0x00007f06d30241d5 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6

and backtrace:
Quote
(gdb) where
#0  0x00007f06d30241d5 in __cxa_allocate_exception ()
   from /usr/lib/libstdc++.so.6
#1  0x00007f06d5c1252b in FIFE::VFS::open (this=0xb63df0, path=@0xdb0f98)
    at engine/core/vfs/vfs.cpp:163
#2  0x00007f06d5c050f0 in FIFE::ImageLoader::loadResource (this=0x765470,
    location=@0xdb0f90)
    at engine/core/loaders/native/video_loaders/image_loader.cpp:49
#3  0x00007f06d5be958c in FIFE::Pool::findAndSetProvider (this=0x77e740,
    entry=@0xdb0f70) at engine/core/util/resource/pool.cpp:204
#4  0x00007f06d5be9ca2 in FIFE::Pool::get (this=0x77e740, index=0, inc=false)
    at engine/core/util/resource/pool.cpp:103
#5  0x00007f06d5bda53f in FIFE::ImagePool::getImage (this=0x77e740, index=0)
    at engine/core/video/imagepool.h:54
#6  0x00007f06d5caaa22 in _wrap_ImagePool_getImage (args=0xbaf2d8)
    at engine/swigwrappers/python/fife_wrap.cxx:77090
#7  0x0000000000417e73 in PyObject_Call ()
#8  0x0000000000486fe3 in PyEval_EvalFrameEx ()
#9  0x000000000048a376 in PyEval_EvalCodeEx ()
#10 0x00000000004d5191 in ?? ()
#11 0x0000000000417e73 in PyObject_Call ()
#12 0x0000000000486fe3 in PyEval_EvalFrameEx ()
#13 0x000000000048a376 in PyEval_EvalCodeEx ()
#14 0x0000000000487fe5 in PyEval_EvalFrameEx ()
---Type <return> to continue, or q <return> to quit---
#15 0x0000000000488b77 in PyEval_EvalFrameEx ()
#16 0x000000000048a376 in PyEval_EvalCodeEx ()
#17 0x00000000004d5191 in ?? ()
#18 0x0000000000417e73 in PyObject_Call ()
#19 0x0000000000486fe3 in PyEval_EvalFrameEx ()
#20 0x000000000048a376 in PyEval_EvalCodeEx ()
#21 0x00000000004d51f8 in ?? ()
#22 0x0000000000417e73 in PyObject_Call ()
#23 0x000000000041e6af in ?? ()
#24 0x0000000000417e73 in PyObject_Call ()
#25 0x000000000045af04 in ?? ()
#26 0x0000000000417e73 in PyObject_Call ()
#27 0x00000000004860ea in PyEval_EvalFrameEx ()
#28 0x000000000048a376 in PyEval_EvalCodeEx ()
#29 0x00000000004d5191 in ?? ()
#30 0x0000000000417e73 in PyObject_Call ()
#31 0x0000000000486fe3 in PyEval_EvalFrameEx ()
#32 0x000000000048a376 in PyEval_EvalCodeEx ()
#33 0x00000000004d51f8 in ?? ()
#34 0x0000000000417e73 in PyObject_Call ()
#35 0x000000000041e6af in ?? ()
#36 0x0000000000417e73 in PyObject_Call ()
#37 0x000000000045af04 in ?? ()
---Type <return> to continue, or q <return> to quit---
#38 0x0000000000417e73 in PyObject_Call ()
#39 0x00000000004860ea in PyEval_EvalFrameEx ()
#40 0x000000000048a376 in PyEval_EvalCodeEx ()
#41 0x00000000004d5191 in ?? ()
#42 0x0000000000417e73 in PyObject_Call ()
#43 0x0000000000486fe3 in PyEval_EvalFrameEx ()
#44 0x000000000048a376 in PyEval_EvalCodeEx ()
#45 0x00000000004d51f8 in ?? ()
#46 0x0000000000417e73 in PyObject_Call ()
#47 0x000000000041e6af in ?? ()
#48 0x0000000000417e73 in PyObject_Call ()
#49 0x000000000045af04 in ?? ()
#50 0x0000000000417e73 in PyObject_Call ()
#51 0x00000000004860ea in PyEval_EvalFrameEx ()
#52 0x0000000000488b77 in PyEval_EvalFrameEx ()
#53 0x0000000000488b77 in PyEval_EvalFrameEx ()
#54 0x0000000000488b77 in PyEval_EvalFrameEx ()
#55 0x0000000000488b77 in PyEval_EvalFrameEx ()
#56 0x000000000048a376 in PyEval_EvalCodeEx ()
#57 0x000000000048a492 in PyEval_EvalCode ()
#58 0x00000000004abdce in PyRun_FileExFlags ()
#59 0x00000000004ac069 in PyRun_SimpleFileExFlags ()
#60 0x00000000004145ad in Py_Main ()
---Type <return> to continue, or q <return> to quit---
#61 0x00007f06d6d7f1c4 in __libc_start_main () from /lib/libc.so.6
#62 0x0000000000413b29 in _start ()

Any ideas? 
Title: Re: Segmentation fault
Post by: mvBarracuda on July 20, 2008, 05:21:22 pm
Hello ChickenGrope :-) Thanks for reporting the bug; we finally managed to write a FAQ entry for it now:
http://wiki.fifengine.net/Frequently_answered_questions#Segfault_in___cxa_allocate_exception

Please try these workarounds and let us know if they worked for you :-)
Title: Re: Segfault in __cxa_allocate_exception
Post by: Sleek on July 20, 2008, 10:56:29 pm
http://mirror1.cvsdude.com/trac/fife/engine/attachment/ticket/297/Exception_tests.4.zip

Please unzip that in the FIFE/tests folder, follow the instruction and run the tests. Describe the result to me :)
Title: Re: Segfault in __cxa_allocate_exception
Post by: mvBarracuda on July 27, 2008, 01:45:28 pm
An article to collect information about systems where the bug occurs / not occurs has been created. If you would like to help us tracking down the issue, please use the following template and either post the result directly at the wiki or here at the forums (I'll add it to the wiki as soon as I spot it in this case):
http://wiki.fifengine.net/Segfault_in_cxa_allocate_exception#Template

EDIT:
I'll resort to the forums this time as IRC communication over different timezones seems tricky.

It looks like your linked exception test is integrated into FIFE somehow sleek. Shouldn't we commit it to trunk in this case so affected users could test it rather easily?
Title: Re: Segfault in __cxa_allocate_exception
Post by: Sleek on July 29, 2008, 04:04:55 am
Sure, I could make it part of svn. However the tests are only for eliminating possible causes of the problem one by one, so I'm not sure if we want the test programs to stay when we have solved this issue. We can just delete them later though so it's probably a good idea.

I'm quite busy right now since I'm taking over operation job in Islamabad, and I also have to renew my visa. So I'll do it when I have the time, or someone can commit it if he can understand what the additional code/script does.
Title: Re: Segfault in __cxa_allocate_exception
Post by: mvBarracuda on August 19, 2008, 06:25:56 am
Yonibear seems to have tracked down the issue. A workaround is in SVN now. Please test the latest FIFE revision and let us know if it works fine for you!

Commit: http://mirror1.cvsdude.com/trac/fife/engine/changeset/2590
Bug report: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219