Hi Noel, this is definitely a variant of the libstdc++/OpenGL bug we describe in the wiki. It seems NVidia had the bug too but fixed it, and now we're seeing the same thing on ATI cards as well. The bug is years old (I'm seeing reports from 2006) and probably impossible to really fix from our side.
There are some workarounds suggested here: http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround, ...or you could just buy an NVidia graphics card. Sounds to me like that would be more cost-effective than spending days trying to get this to run. (But if you do keep working on this, please let us know & I'll try to help.) Sorry, Uli Noel Corbett wrote: > Hi All, > New information, I've been toying around with this all day as I have some > need to get this machine running. > The problems are related to the ATI driver obviously and the initial seg > fault is from the Logger trace function trying to output information (note > that player.loadFile works fine so long as there is valid input the seg > faults I was experiencing were simply Logger trace problems). I managed to > get slightly further into starting the program by simply commenting out some > stuff in Logger.cpp and found that the program crashes wherever it tries to > use string functions for formatting or anything like that. > After that I did some googling and found that some other similar projects > have had problems like this. My C++ skills leave something to be desired and > I'm uncertain as to what some of the proposed solutions call for but if you > look at Segfault in __cxa_allocate_exception in the following wiki > http://wiki.fifengine.de/index.php?title=Frequently_answered_questions#Segfault_in___cxa_allocate_exception > and this page here: > http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception > One option that I will try perhaps tomorrow is to compile using an older GCC > namely 4.1 and see if that helps > > Here is a recent backtrace you'll see the logger trace function is one of > the last to call > #0 0xb6a0e077 in std::uncaught_exception () from /usr/lib/libstdc++.so.6 > #1 0xb69df335 in std::__ostream_insert<char, std::char_traits<char> > () > from /usr/lib/libstdc++.so.6 > #2 0xb7c6d5cf in avg::Logger::trace (this=0x8207580, category=64, > [EMAIL PROTECTED]) at /usr/include/c++/4.2/ostream:517 > #3 0xb7c5cc9f in avg::OGLShader::dumpInfoLog (this=0x876a638, hObj=1) at > OGLShader.cpp:108 > #4 0xb7c5d02a in OGLShader (this=0x876a638, [EMAIL PROTECTED]) at > OGLShader.cpp:41 > #5 0xb7bb414e in avg::SDLDisplayEngine::checkYCbCrSupport (this=0x821e6e8) > at SDLDisplayEngine.cpp:684 > #6 0xb7bb68e7 in avg::SDLDisplayEngine::init (this=0x821e6e8, > [EMAIL PROTECTED]) at SDLDisplayEngine.cpp:318 > #7 0xb7bd364e in avg::Player::initGraphics (this=0x81f24c0) at > Player.cpp:823 > #8 0xb7be07f9 in avg::Player::initPlayback (this=0x81f24c0) at > Player.cpp:304 > #9 0xb7be09e2 in avg::Player::play (this=0x81f24c0) at Player.cpp:264 > #10 0xb7b51ba5 in > boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void > (avg::Player::*)(), boost::python::default_call_policies, > boost::mpl::vector2<void, avg::Player&> > >::operator() (this=0x81e3dd8, > args=0xb7d9358c, kw=0x0) > at /usr/include/boost/python/detail/invoke.hpp:94 > #11 0xb6ba59b0 in boost::python::objects::function::call () from > /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #12 0xb6ba5bd7 in ?? () from /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #13 0xb7a5301b in boost::function0<void, > std::allocator<boost::function_base> >::operator() () from > /usr/lib/libboost_thread-gcc42-mt-1_34_1.so.1.34.1 > #14 0xb6bad2b3 in boost::python::detail::exception_handler::operator() () > from /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #15 0xb7b4d072 in > boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, > boost::python::detail::translate_exception<avg::Exception, void > (*)(avg::Exception const&)>, boost::_bi::list3<boost::arg<1> (*)(), > boost::arg<2> (*)(), boost::_bi::value<void (*)(avg::Exception const&)> > >, > bool, boost::python::detail::exception_handler const&, > boost::function0<void, std::allocator<boost::function_base> > > const&>::invoke ( > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at > /usr/include/boost/python/detail/translate_exception.hpp:46 > #16 0xb6bad5d9 in boost::function2<bool, > boost::python::detail::exception_handler const&, boost::function0<void, > std::allocator<boost::function_base> > const&, > std::allocator<boost::function_base> >::operator() () from > /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #17 0xb6bad116 in boost::python::handle_exception_impl () from > /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #18 0xb6ba33fe in ?? () from /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 > #19 0x0805cb97 in PyObject_Call () > #20 0x080c7aa7 in PyEval_EvalFrameEx () > #21 0x080cb1f7 in PyEval_EvalCodeEx () > #22 0x080cb347 in PyEval_EvalCode () > #23 0x080ea818 in PyRun_FileExFlags () > #24 0x080eaab9 in PyRun_SimpleFileExFlags () > #25 0x08059335 in Py_Main () > #26 0x080587f2 in main () > > > Hope I'm on the right track with this and not wasting your time. > > Cheers > Noel > > > On Tue, Aug 26, 2008 at 10:48 AM, Noel Corbett <[EMAIL PROTECTED]> wrote: > >> >> On Tue, Aug 26, 2008 at 10:07 AM, Ulrich von Zadow <[EMAIL PROTECTED]>wrote: >> >>> Hi, >>> >>> now we're getting to a point where I'm not sure what's up. I might have >>> to try and install on an ATI machine myself one of these days to see >>> what's going on. >>> >>> Noel Corbett wrote: >>> >>>> glxinfo >>> Looks ok... >>> >>>> src/graphics/testgpu >>>> X Error of failed request: BadDrawable (invalid Pixmap or Window >>> parameter) >>>> Major opcode of failed request: 145 (XFree86-DRI) >>>> Minor opcode of failed request: 7 () >>>> Resource id in failed request: 0x800003 >>>> Serial number of failed request: 28 >>>> Current serial number in output stream: 28 >>> This doesn't give you a coredump, right? >> >> Correct there is no coredump >> This is the latest SVN by the way and using the latest ATI proprietary >> drivers from their site. >> >> >>> >>>> segfault from running 'python sunriver2.py' >>>> #0 0xb69f9e26 in __cxa_allocate_exception () from >>> /usr/lib/libstdc++.so.6 >>>> #1 0xb6b98fbe in boost::python::throw_error_already_set () from >>>> /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 >>>> #2 0xb6b914c5 in boost::python::objects::function::argument_error () >>> from >>>> /usr/lib/libboost_python-gcc42-1_34_1.so.1.34.1 >>> That's a pretty wild stack... >>> >>> What's in sunriver2.py? Do you get the same crash running Test.py? What >>> output is produced before the crash? How far into the python code do you >>> get? >>> >> Nothing special, running an interactive python prompt gets the same result >> using the following >> >> from libavg import avg >> player = avg.Player() >> player.loadfile() <- SegFaults here doesn't matter what's contained within >> the parenthesis >> >> Which is interesting, I would assume that avg wouldn't yet be doing >> anything graphics related >> >> >> Cheers >> Noel >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > libavg-users mailing list > [email protected] > https://mail.datenhain.de/mailman/listinfo/libavg-users -- Any technology distinguishable from magic is insufficiently advanced. Ulrich von Zadow | +49-172-7872715 Jabber: [EMAIL PROTECTED] Skype: uzadow _______________________________________________ libavg-users mailing list [email protected] https://mail.datenhain.de/mailman/listinfo/libavg-users
