Hi, Thanks for you help with this so far, at very least I've learnt a bit about debugging programs. Tell me though, one of the suggested solutions is to explicitly link libstdc++ before the opengl library, they do this in a python configuration script that appears to add it to LIBS. how would I do this using the Makefile?
Cheers Noel On Tue, Aug 26, 2008 at 8:19 PM, Ulrich von Zadow <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ libavg-users mailing list [email protected] https://mail.datenhain.de/mailman/listinfo/libavg-users
