Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ape]

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

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 ()

[chewie]

@ape

Did you

Code: [Select]

scons ext=1 && scons

? Scons ext=1 alone won't do the trick ;-)

[mvBarracuda]

Yep he did :-) he was on the channel some hours ago and ran both commands but forgot to mention that in his posting.

[anxs]

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...

[skybound]

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.

[mvBarracuda]

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.

[mvBarracuda]

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 :-)

[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.

[skybound]

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?

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.

[mvBarracuda]

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

[nouri]

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?

[jasoka]

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.

[Sleek]

For anyone having this problem, please do a

Code: [Select]

gcc --version

and post your result here. Thanks.

[nouri]

Code: [Select]

daniel@redhotcar:~$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)


[Sleek]

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

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.