User talk:Mvanga

From WorldForgeWiki
Jump to: navigation, search

Could you give some more info on the situation where you're getting library errors when running Ember? That should normally not happen, so I would like to fix it in the code or script.--Erik 07:03, 12 February 2010 (UTC)

Errors

Sure thing!

It happens while (apparently) parsing the Common.program script. I tried debugging it with GDB but the stack frame gets corrupted so I can't tell exactly where the issue is. The exact error is:

$ ./ember
According to my calculations Ember should be installed in /home/mvanga/source/wf/hammer/hammer/local/bin/..
Starting Ember....
Starting Ember version 0.5.8
Initializing Ember services
Setting home directory to /home/mvanga/.ember
Crashed with signal 11, will try to shut down SDL gracefully. Please report bugs at https://bugs.launchpad.net/ember
./ember: line 118:  6014 Segmentation fault      $bindir/ember.bin --home $homedata "$@"

This is what my log looks like after the crash:

$ tail ~/.ember/ember.log 
[08:29:10] INFO (Ogre) Parsing scripts for resource group Gui
[08:29:10] INFO (Ogre) Finished parsing scripts for resource group Gui
[08:29:10] INFO Looking for /home/mvanga/source/wf/hammer/hammer/local/share/ember//media/shared/common/
[08:29:10] INFO Adding dir /home/mvanga/source/wf/hammer/hammer/local/share/ember//media/shared/common/
[08:29:10] INFO (Ogre) Added resource location '/home/mvanga/source/wf/hammer/hammer/local/share/ember//media/shared/common/' of type 'EmberFileSystem' to resource group 'General' with recursive option
[08:29:10] INFO Looking for /home/mvanga/source/wf/hammer/hammer/local/share/ember//media/shared/models/
[08:29:10] INFO Looking for /home/mvanga/source/wf/hammer/hammer/local/share/ember//media/shared/sounds/
[08:29:10] INFO (Ogre) Initialising resource group General
[08:29:10] INFO (Ogre) Parsing scripts for resource group General
[08:29:11] INFO (Ogre) Parsing script resources/ogre/scripts/programs/Common.program

Additional Info

Just to clarify, it was a no nonsense direct install through the Hammer script.

Ok, could you run it with gdb and post the backtrace anyway? Use the command "ember --debug" and it will start gdb with all the env params already set.--Erik 08:05, 12 February 2010 (UTC)

gdb backtrace

Here you go...updated it with some useful stuff...perhaps it will help:

$ ./ember --debug
According to my calculations Ember should be installed in /home/mvanga/source/wf/hammer/hammer/local/bin/..
Starting Ember in debugger....
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /home/mvanga/source/wf/hammer/hammer/local/bin/ember.bin --home /home/mvanga/.ember
[Thread debugging using libthread_db enabled]
Starting Ember version 0.5.8
Initializing Ember services
Setting home directory to /home/mvanga/.ember
[New Thread 0xb5e326d0 (LWP 9139)]
[New Thread 0xb5dcdb90 (LWP 9142)]
[New Thread 0xb53cbb90 (LWP 9143)]
[New Thread 0xb00bfb90 (LWP 9146)]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb5e326d0 (LWP 9139)]
0xb6559393 in strlen () from /lib/i686/cmov/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 0xb5e326d0 (LWP 9139))]#0  0xb6559393 in strlen () from /lib/i686/cmov/libc.so.6
(gdb) backtrace
#0  0xb6559393 in strlen () from /lib/i686/cmov/libc.so.6
#1  0xb651761d in ?? () from /lib/i686/cmov/libc.so.6
#2  0xb661f116 in ?? () from /lib/i686/cmov/libc.so.6
#3  0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0xb5dcdb90 (LWP 9142))]#0  0xb7fa9424 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xb7fa9424 in __kernel_vsyscall ()
#1  0xb65b8e67 in poll () from /lib/i686/cmov/libc.so.6
#2  0xb5deec22 in ?? () from /usr/lib/libpulse.so.0
#3  0x0a009d90 in ?? ()
#4  0x00000002 in ?? ()
#5  0xb5de2079 in pa_mainloop_dispatch () from /usr/lib/libpulse.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread 3
[Switching to thread 3 (Thread 0xb53cbb90 (LWP 9143))]#0  0xb7fa9424 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xb7fa9424 in __kernel_vsyscall ()
#1  0xb65b8e67 in poll () from /lib/i686/cmov/libc.so.6
#2  0xb61973b5 in ?? () from /usr/lib/libasound.so.2
#3  0xb53cb220 in ?? ()
#4  0x00000001 in ?? ()
#5  0xb61d75e5 in ?? () from /usr/lib/libasound.so.2
#6  0x0a009b48 in ?? ()
#7  0x0a009b48 in ?? ()
#8  0xb53cb218 in ?? ()
#9  0xb6191bc1 in snd_pcm_poll_descriptors_count () from /usr/lib/libasound.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread 4
[Switching to thread 4 (Thread 0xb00bfb90 (LWP 9146))]#0  0xb7fa9422 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xb7fa9422 in __kernel_vsyscall ()
#1  0xb71d6025 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0
#2  0xb71c4ff4 in boost::detail::condition_impl::do_wait () from /usr/lib/libboost_thread-gcc42-mt-1_34_1.so.1.34.1
#3  0xb7c8d872 in Ogre::ResourceBackgroundQueue::threadFunc () at /usr/include/boost/thread/condition.hpp:150
#4  0xb7c8e7cb in boost::detail::function::void_function_invoker0<void (*)(), void>::invoke (function_ptr=@0xb00bf390) at /usr/include/boost/function/function_template.hpp:117
#5  0xb71c7f4c in boost::function0<void, std::allocator<boost::function_base> >::operator() () from /usr/lib/libboost_thread-gcc42-mt-1_34_1.so.1.34.1
#6  0xb71c7b87 in ?? () from /usr/lib/libboost_thread-gcc42-mt-1_34_1.so.1.34.1
#7  0xb71d24c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#8  0xb65c36de in clone () from /lib/i686/cmov/libc.so.6
(gdb) step
Single stepping until exit from function __kernel_vsyscall, 
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5e326d0 (LWP 9139)]
0xb4790ce1 in _slang_alloc_statevar () from /usr/lib/dri/i965_dri.so
(gdb) 


Hi, perhaps we could continue the discussion either at the mailing list or the forum? Unfortunately it looks like this is an error within the Mesa library though. You don't need to provide backtraces of all threads, it's sufficient with the one causing the crash. But it would be useful if you could provide a complete backtrace with all frames. --Erik 12:13, 12 February 2010 (UTC)