Hi,
you know, that might actually work...
I've attached a patch that adds libstdc++ to the link line whenever we
link to opengl. See if it works - and if so, I'll commit it to svn.
Cheers,
Uli
Noel Corbett wrote:
> 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
>>>>
--
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: [EMAIL PROTECTED]
Skype: uzadow
Index: m4/ax_check_gl.m4
===================================================================
--- m4/ax_check_gl.m4 (revision 3079)
+++ m4/ax_check_gl.m4 (working copy)
@@ -264,13 +264,15 @@
done
LIBS=${ax_save_LIBS}
CPPFLAGS=${ax_save_CPPFLAGS}])
-
if test "X${ax_cv_check_gl_libgl}" = "Xno"; then
no_gl="yes"
GL_CFLAGS=""
GL_LIBS=""
else
GL_LIBS="${ax_cv_check_gl_libgl} ${GL_LIBS}"
+ if test $target_vendor != apple; then
+ GL_LIBS="-lstdc++ ${GL_LIBS}"
+ fi
fi
AC_LANG_POP(C)
fi
_______________________________________________
libavg-users mailing list
[email protected]
https://mail.datenhain.de/mailman/listinfo/libavg-users
