Robert Osfield wrote:
>On 8/29/07, Paul Melis <[EMAIL PROTECTED]> wrote:
>
>
>>After just updating to 2.1.8 and compiling I noticed that osgviewer will
>>hang when exiting most of the time. This only happens when statistics
>>are shown when escape is pressed (which mode of statistics doesn't seem
>>to matter). Using strace shows that osgviewer is blocked on a futex(...,
>>FUTEX_WAIT) call.
>>I tried the different threading models and only seem to get the lockup
>>with --DrawThreadPerContext (is this the default?).
>>
>>Paul
>>
>>PS This is on a FC4 system, with a hyperthreaded Xeon.
>>
>>
>
>Curious... I have no clue what a futex(..) is, it must be something
>implemented deep down on pthreads or the c library. Could you get a
>full stack trace?
>
>
Here you go...
The futex indeed seems to come from pthreads (although its not listed at
the top of this gdb stack trace).
The destruction of a Scene object seems to be causing the lockup here.
(gdb) bt
#0 0x00748402 in ?? ()
#1 0x009b7f5e in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#2 0x009b4c7d in _L_mutex_lock_36 () from /lib/libpthread.so.0
#3 0xbf897358 in ?? ()
#4 0x0058f144 in ?? () from /home/paul/local/lib/libOpenThreads.so.7
#5 0x087bf288 in ?? ()
#6 0x00549d78 in s_sceneCache () from
/home/paul/local/lib/libosgViewer.so.19
#7 0xbf897368 in ?? ()
#8 0x0058e1e2 in OpenThreads::Mutex::lock (this=0x861ddbc)
at /home/paul/c/osg-svn/src/OpenThreads/pthreads/PThreadMutex.c++:122
#9 0x0058e1e2 in OpenThreads::Mutex::lock (this=0x549d78)
at /home/paul/c/osg-svn/src/OpenThreads/pthreads/PThreadMutex.c++:122
#10 0x004fea47 in ~Scene (this=0x861f440)
at /home/paul/c/osg-svn/include/OpenThreads/ScopedLock:31
#11 0x00cea7c6 in osg::DeleteHandler::flushAll (this=0x86e40e0)
at /home/paul/c/osg-svn/include/osg/DeleteHandler:57
#12 0x0052f643 in __tcf_1 ()
at /home/paul/c/osg-svn/src/osgViewer/GraphicsWindowX11.cpp:1283
#13 0x00a90bbf in __cxa_finalize () from /lib/libc.so.6
#14 0x004e63d6 in __do_global_dtors_aux ()
from /home/paul/local/lib/libosgViewer.so.19
#15 0x00537102 in _fini () from /home/paul/local/lib/libosgViewer.so.19
#16 0x00757268 in _dl_fini () from /lib/ld-linux.so.2
---Type <return> to continue, or q <return> to quit---
#17 0x00a90949 in exit () from /lib/libc.so.6
#18 0x00a7ad87 in __libc_start_main () from /lib/libc.so.6
#19 0x0804a419 in _start ()
>W.r.t the default, the threading model is chosen at runtime, if you
>have just a single core then it'll plump to SingleThreaded, if you
>have two cores and one context it'll choose DrawThreadPerContext, one
>my quad core system with two cards it chooses
>CullPerCameraDrawThreadPerContext.
>
>
Check
>On you system most likely it'll be choosing DrawThreadPerContext.
>DrawThreadPerContext and CullPerCameraDrawThreadPerContext use the
>osg::DeleteHandler to cache deleted objects to prevent them from being
>deleted while still being rendered. I have noticed occasional problems
>with exit due to the DeleteHandler changing the final deletion order,
>so am reviewing what to do about this class and how to manage
>DrawThreadPerContext and CullPerCameraDrawThreadPerContext without
>needing the services of DeleteHandler.
>
>
It is indeed triggered from a DeleteHandler object, as the stack trace shows
Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
