Re: [osg-users] Crash with DrawThreadPerContext
Hi Robert, Hi Tugkan, Are you able to get a stack trace? Yes, attached. This is the console output of the program, which I sent you yesterday, when it is started in gdb. It is taken on Suse10.2, Core 2 Duo, Quaddro FX 4500. The line Failed to read a valid object file image from memory. seems to have something to do with gdb and kernel. It seemed suspicious to me but crash happens even if I start without gdb. My first email in this thread contains the stack trace of the crash of our OSG based application. It is taken on Suse9.3, Core 2 Duo, GF7900GTX x2. Note that in our application crash was occuring only in DrawThreadPerContext mode. The program I sent you works in SingleThreaded mode but from the console output it can be seen that it crashes just after the draw thread exits. The stack traces are pretty similar. One difference is that in one of them attribute argument is NULL where as the other one seems to have a valid looking (but invalid) value. tugkan Robert. On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? This seems strange. I have made the tests with SVN version from yesterday morning. After your email I made one more update and recompiled everything. I still observe the problems. I went on to a different computer (different HW and OS version) and made a fresh checkout. Still the same crash (with the same backtrace) and freeze. Here are the test systems: Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46 Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46 I'd like to debug it myself here but I don't know what to look for. -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - stacktrace.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Tugkan, From the stack trace it looks to me like a StateSet or StateAttribute has been deleted while the rendering thread is still using it. This something that can happen in the DrewThreadPerContext/CullThreadPerCameraDrawThreadPerContext thread models if objects are deleted and the DeleteHandler isn't set up correctly to prevent deletion. In you latest stack strace it doesn't seem to be these thread models that are active. Perhaps most telling is the warning: Warning: deleting still referenced object 0x8105d80 of type 'PN3osg10ReferencedE' the final reference count was 1, memory corruption possible. Emitted by osg::Referenced is a clear indication that something odd is up w.r.t reference counting. Perhaps a thread safe ref/unref hasn't been enable for this object. I would be interesting adding a bit more debug output to Referenced to see if we can get more info about what type of object is exhibiting this problem. Putting an abort() into this code segment would be useful is catching the stack trace at the point. Since I haven't been able to recreate the problem could you try sticking an abort into osg::Referenced to see where its being called from. Robert. On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Are you able to get a stack trace? Yes, attached. This is the console output of the program, which I sent you yesterday, when it is started in gdb. It is taken on Suse10.2, Core 2 Duo, Quaddro FX 4500. The line Failed to read a valid object file image from memory. seems to have something to do with gdb and kernel. It seemed suspicious to me but crash happens even if I start without gdb. My first email in this thread contains the stack trace of the crash of our OSG based application. It is taken on Suse9.3, Core 2 Duo, GF7900GTX x2. Note that in our application crash was occuring only in DrawThreadPerContext mode. The program I sent you works in SingleThreaded mode but from the console output it can be seen that it crashes just after the draw thread exits. The stack traces are pretty similar. One difference is that in one of them attribute argument is NULL where as the other one seems to have a valid looking (but invalid) value. tugkan Robert. On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? This seems strange. I have made the tests with SVN version from yesterday morning. After your email I made one more update and recompiled everything. I still observe the problems. I went on to a different computer (different HW and OS version) and made a fresh checkout. Still the same crash (with the same backtrace) and freeze. Here are the test systems: Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46 Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46 I'd like to debug it myself here but I don't know what to look for. -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Robert, The message comes from osg::AlphaFunc. I've attached the stack trace. I've added af-setThreadSafeRefUnref( true ) but this didn't change anything. The message still comes and crash occurs with the same stack trace. I've done the same for the state set also and nothing changed. tugkan Hi Tugkan, From the stack trace it looks to me like a StateSet or StateAttribute has been deleted while the rendering thread is still using it. This something that can happen in the DrewThreadPerContext/CullThreadPerCameraDrawThreadPerContext thread models if objects are deleted and the DeleteHandler isn't set up correctly to prevent deletion. In you latest stack strace it doesn't seem to be these thread models that are active. Perhaps most telling is the warning: Warning: deleting still referenced object 0x8105d80 of type 'PN3osg10ReferencedE' the final reference count was 1, memory corruption possible. Emitted by osg::Referenced is a clear indication that something odd is up w.r.t reference counting. Perhaps a thread safe ref/unref hasn't been enable for this object. I would be interesting adding a bit more debug output to Referenced to see if we can get more info about what type of object is exhibiting this problem. Putting an abort() into this code segment would be useful is catching the stack trace at the point. Since I haven't been able to recreate the problem could you try sticking an abort into osg::Referenced to see where its being called from. Robert. On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Are you able to get a stack trace? Yes, attached. This is the console output of the program, which I sent you yesterday, when it is started in gdb. It is taken on Suse10.2, Core 2 Duo, Quaddro FX 4500. The line Failed to read a valid object file image from memory. seems to have something to do with gdb and kernel. It seemed suspicious to me but crash happens even if I start without gdb. My first email in this thread contains the stack trace of the crash of our OSG based application. It is taken on Suse9.3, Core 2 Duo, GF7900GTX x2. Note that in our application crash was occuring only in DrawThreadPerContext mode. The program I sent you works in SingleThreaded mode but from the console output it can be seen that it crashes just after the draw thread exits. The stack traces are pretty similar. One difference is that in one of them attribute argument is NULL where as the other one seems to have a valid looking (but invalid) value. tugkan Robert. On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? This seems strange. I have made the tests with SVN version from yesterday morning. After your email I made one more update and recompiled everything. I still observe the problems. I went on to a different computer (different HW and OS version) and made a fresh checkout. Still the same crash (with the same backtrace) and freeze. Here are the test systems: Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46 Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46 I'd like to debug it myself here but I don't know what to look for. -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net
Re: [osg-users] Crash with DrawThreadPerContext
Hi Robert,
In include/osg/DeleteHandler there is following method:
inline void doDelete(const Referenced* object) { delete object; }
Shouldn't it be object-unref() instead?
tugkan
Hi Robert,
The message comes from osg::AlphaFunc. I've attached the stack trace.
I've added af-setThreadSafeRefUnref( true ) but this didn't change
anything. The message still comes and crash occurs with the same stack
trace. I've done the same for the state set also and nothing changed.
tugkan
Hi Tugkan,
From the stack trace it looks to me like a StateSet or StateAttribute
has been deleted while the rendering thread is still using it. This
something that can happen in the
DrewThreadPerContext/CullThreadPerCameraDrawThreadPerContext thread
models if objects are deleted and the DeleteHandler isn't set up
correctly to prevent deletion. In you latest stack strace it doesn't
seem to be these thread models that are active.
Perhaps most telling is the warning:
Warning: deleting still referenced object 0x8105d80 of type
'PN3osg10ReferencedE'
the final reference count was 1, memory corruption possible.
Emitted by osg::Referenced is a clear indication that something odd is
up w.r.t reference counting. Perhaps a thread safe ref/unref hasn't
been enable for this object. I would be interesting adding a bit more
debug output to Referenced to see if we can get more info about what
type of object is exhibiting this problem. Putting an abort() into
this code segment would be useful is catching the stack trace at the
point.
Since I haven't been able to recreate the problem could you try
sticking an abort into osg::Referenced to see where its being called
from.
Robert.
On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote:
Hi Robert,
Hi Tugkan,
Are you able to get a stack trace?
Yes, attached. This is the console output of the program, which I sent
you yesterday, when it is started in gdb. It is taken on Suse10.2, Core
2 Duo, Quaddro FX 4500. The line Failed to read a valid object file
image from memory. seems to have something to do with gdb and kernel.
It seemed suspicious to me but crash happens even if I start without
gdb.
My first email in this thread contains the stack trace of the crash of
our OSG based application. It is taken on Suse9.3, Core 2 Duo, GF7900GTX
x2. Note that in our application crash was occuring only in
DrawThreadPerContext mode. The program I sent you works in
SingleThreaded mode but from the console output it can be seen that it
crashes just after the draw thread exits.
The stack traces are pretty similar. One difference is that in one of
them attribute argument is NULL where as the other one seems to have a
valid looking (but invalid) value.
tugkan
Robert.
On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote:
Hi Robert,
Hi Tugkan,
Thanks for the example code. I've enable the compile of each of
the
three #if #elif sections in term and they are run and exit cleanly.
Nothing appers to be amiss. Are you using the latest OSG in SVN?
This seems strange.
I have made the tests with SVN version from yesterday morning.
After your email I made one more update and recompiled everything. I
still observe the problems.
I went on to a different computer (different HW and OS version)
and made
a fresh checkout. Still the same crash (with the same backtrace) and
freeze.
Here are the test systems:
Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46
Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46
I'd like to debug it myself here but I don't know what to look for.
--
Tugkan Calapoglu
-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Tugkan Calapoglu
-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-
___
osg-users mailing list
osg-users@openscenegraph.net
Re: [osg-users] Crash with DrawThreadPerContext
Hi Tugkan,
On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote:
Hi Robert,
In include/osg/DeleteHandler there is following method:
inline void doDelete(const Referenced* object) { delete object; }
Shouldn't it be object-unref() instead?
No, the DeleteHandler does the actual delete itself. Objects
shouldn't get into the DeleteHandler unless their ref count has gone
to zero and they are ready for deletion.
Perhaps one could add a check into the DeleteHandler so it double
checks the ref count on objects being added and when they are about to
be deleted. This might catch this problem case from causing a crash,
but there is clearly a problem further upstream.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
HI Tugkan, On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, The message comes from osg::AlphaFunc. I've attached the stack trace. I've added af-setThreadSafeRefUnref( true ) but this didn't change anything. The message still comes and crash occurs with the same stack trace. I've done the same for the state set also and nothing changed. It wonder where this AlphaFunc was attached, it could be its StateSet is the one with the problems with thread safe ref/unref. One thing you could try is sticking a: osg::Referenced::setThreadSafeReferenceCounting(true); At the top of the main. Robert. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Robert, This was a step in the correct direction I think. Adding osg::Referenced::setThreadSafeReferenceCounting(true); solved the problem. I removed all setThreadSafeRefUnref()'s and it was still ok. Maybe setThreadSafeReferenceCounting should be automatically enabled depending on the threading mode. However, now I observe a crash when I cycle through the modes with 'm' and come back to DrawThreadPerContext mode. Application starts with default threading mode then I set to SingleThreaded in code and then in runtime I go to DrawThreadPerContext again. You can find the stack trace and the code I used as attachment. HI Tugkan, On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, The message comes from osg::AlphaFunc. I've attached the stack trace. I've added af-setThreadSafeRefUnref( true ) but this didn't change anything. The message still comes and crash occurs with the same stack trace. I've done the same for the state set also and nothing changed. It wonder where this AlphaFunc was attached, it could be its StateSet is the one with the problems with thread safe ref/unref. One thing you could try is sticking a: osg::Referenced::setThreadSafeReferenceCounting(true); At the top of the main. Robert. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - stackTrace3.tar.gz Description: GNU Zip compressed data osgviewer.cpp.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Tugkan, On 2/23/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: This was a step in the correct direction I think. Adding osg::Referenced::setThreadSafeReferenceCounting(true); solved the problem. I removed all setThreadSafeRefUnref()'s and it was still ok. Maybe setThreadSafeReferenceCounting should be automatically enabled depending on the threading mode. This is what osgProducer does, but this requires the user to constuct the viewer and the threading model before loading the scene graph. For osgViewer I have tried to do the setting when required and allow construction order of viewer/scene graph to be interchangable. What we are missing is is a setThreadSafeRefUnRef on the objects that are being a problem, we just need to isolate which objects they are. However, now I observe a crash when I cycle through the modes with 'm' and come back to DrawThreadPerContext mode. Application starts with default threading mode then I set to SingleThreaded in code and then in runtime I go to DrawThreadPerContext again. You can find the stack trace and the code I used as attachment. The stack trace is again associated with StateSet's so it sounds like we have the same issue just appearing in different places. I'll download load your latest modified osgviewer to see if I can recreate the same errors, if I can then tracking down and fix the problem will become a lot easier. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? W.r.t when its safe to modify the scene graph, its safe to modify any DYNAMIC scene graph leaves (Drawable + StateSet) any time outwith the Viewer::renderingTraversals() call. When you aren't running DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext there isn't even the limitation of modification of just DYNAMIC scene graph leaves. As to what might be amiss at your end I don't know. Robert. On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: I've worked more on the subject and repeated the crash in a simple application derived from osgviewer. You can find it attached. Unlike our application it also happens in SingleTreaded mode here. As far as I understand the new threading system it should be safe to access the scene graph outside the frame() method. And anyway it is single threaded mode here. As I was working on this problem I ran into another problem also. If I call viewer.getCamera()-getOrCreateStateSet()-setDataVariance( osg::Object::DYNAMIC ) before the main loop and switch to DrawThreadPerContext mode using 'm' application freezes. See if blocks at the end of the main(). First block is for freezing and the second block is for crash. Tugkan - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Robert, Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? This seems strange. I have made the tests with SVN version from yesterday morning. After your email I made one more update and recompiled everything. I still observe the problems. I went on to a different computer (different HW and OS version) and made a fresh checkout. Still the same crash (with the same backtrace) and freeze. Here are the test systems: Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46 Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46 I'd like to debug it myself here but I don't know what to look for. -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
Hi Tugkan, Are you able to get a stack trace? Robert. On 2/22/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi Robert, Hi Tugkan, Thanks for the example code. I've enable the compile of each of the three #if #elif sections in term and they are run and exit cleanly. Nothing appers to be amiss. Are you using the latest OSG in SVN? This seems strange. I have made the tests with SVN version from yesterday morning. After your email I made one more update and recompiled everything. I still observe the problems. I went on to a different computer (different HW and OS version) and made a fresh checkout. Still the same crash (with the same backtrace) and freeze. Here are the test systems: Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46 Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46 I'd like to debug it myself here but I don't know what to look for. -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Crash with DrawThreadPerContext
Hi, I've run into a problem regarding DrawThreadPerContext mode. At the moment our application is stable with other threading modes but in DrawThreadPerContext mode it crashes in a few seconds. I've updated OSG from SVN today in the morning. Platform is SusE9.3, Intel Core 2 Duo. Stack trace is at the end of the email. Note the 'attribute=0x0' in the beginning (#0) osgviewer alone works well with the same models. So something that is done in runtime should be the reason. However I can not see what can be done wrong to have a NULL attribute there ( StateSet::setAttribute* methods check whether the input argument is NULL so I think that possiblity is ruled out). I've simplified our application to such a degree that it does not render anything. It just starts a viewer and thats it. Still it crashes. #0 0x40ddbf9e in osg::State::applyAttribute (this=0x813e750, attribute=0x0, [EMAIL PROTECTED]) at ../../../include/osg/State:927 #1 0x40e88cfc in osg::State::applyAttributeList (this=0x813e750, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../include/osg/State:1422 #2 0x40e84981 in osg::State::apply (this=0x813e750, dstate=0xa4c4848) at ../State.cpp:301 #3 0x4124fbe2 in osgUtil::RenderLeaf::render (this=0x8105648, [EMAIL PROTECTED], previous=0x0) at ../RenderLeaf.cpp:71 #4 0x412461f4 in osgUtil::RenderBin::drawImplementation (this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:427 #5 0x41245f45 in osgUtil::RenderBin::draw (this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370 #6 0x4124638c in osgUtil::RenderBin::drawImplementation (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:457 #7 0x41256400 in osgUtil::RenderStage::drawImplementation (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:1004 #8 0x41245f45 in osgUtil::RenderBin::draw (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370 #9 0x412556c6 in osgUtil::RenderStage::drawInner (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:718 #10 0x41255e5a in osgUtil::RenderStage::draw (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:880 #11 0x41264864 in osgUtil::SceneView::draw (this=0xbf526d8) at ../SceneView.cpp:1305 #12 0x41709776 in ViewerDoubleBufferedRenderingOperation::draw (this=0x8104bf8) at ../Viewer.cpp:411 #13 0x4170765b in ViewerDoubleBufferedRenderingOperation::operator() (this=0x8104bf8, object=0x80f9a78) at ../Viewer.cpp:544 #14 0x40e1ba0f in osg::GraphicsContext::runOperations (this=0x80f9a78) at ../GraphicsContext.cpp:426 #15 0x41707ca3 in ViewerRunOperations::operator() (this=0xf1fbba8, object=0x80f9a78) at ../Viewer.cpp:969 #16 0x40e21416 in osg::OperationsThread::run (this=0x91b7910) at ../GraphicsThread.cpp:290 #17 0x414528f5 in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib/libOpenThreads.so #18 0x414fdaa7 in start_thread () from /lib/tls/libpthread.so.0 #19 0x40b96c2e in clone () from /lib/tls/libc.so.6 -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Crash with DrawThreadPerContext
HI Tugkan, The most likely cause is state or drawables being updated while the draw thread is still reading from them, the mechanism to prevent the them overlapping this is based on the use of DataVariance being set to DYNAMIC. See my previous posts on this topic. Robert. On 2/21/07, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi, I've run into a problem regarding DrawThreadPerContext mode. At the moment our application is stable with other threading modes but in DrawThreadPerContext mode it crashes in a few seconds. I've updated OSG from SVN today in the morning. Platform is SusE9.3, Intel Core 2 Duo. Stack trace is at the end of the email. Note the 'attribute=0x0' in the beginning (#0) osgviewer alone works well with the same models. So something that is done in runtime should be the reason. However I can not see what can be done wrong to have a NULL attribute there ( StateSet::setAttribute* methods check whether the input argument is NULL so I think that possiblity is ruled out). I've simplified our application to such a degree that it does not render anything. It just starts a viewer and thats it. Still it crashes. #0 0x40ddbf9e in osg::State::applyAttribute (this=0x813e750, attribute=0x0, [EMAIL PROTECTED]) at ../../../include/osg/State:927 #1 0x40e88cfc in osg::State::applyAttributeList (this=0x813e750, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../include/osg/State:1422 #2 0x40e84981 in osg::State::apply (this=0x813e750, dstate=0xa4c4848) at ../State.cpp:301 #3 0x4124fbe2 in osgUtil::RenderLeaf::render (this=0x8105648, [EMAIL PROTECTED], previous=0x0) at ../RenderLeaf.cpp:71 #4 0x412461f4 in osgUtil::RenderBin::drawImplementation (this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:427 #5 0x41245f45 in osgUtil::RenderBin::draw (this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370 #6 0x4124638c in osgUtil::RenderBin::drawImplementation (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:457 #7 0x41256400 in osgUtil::RenderStage::drawImplementation (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:1004 #8 0x41245f45 in osgUtil::RenderBin::draw (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370 #9 0x412556c6 in osgUtil::RenderStage::drawInner (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:718 #10 0x41255e5a in osgUtil::RenderStage::draw (this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:880 #11 0x41264864 in osgUtil::SceneView::draw (this=0xbf526d8) at ../SceneView.cpp:1305 #12 0x41709776 in ViewerDoubleBufferedRenderingOperation::draw (this=0x8104bf8) at ../Viewer.cpp:411 #13 0x4170765b in ViewerDoubleBufferedRenderingOperation::operator() (this=0x8104bf8, object=0x80f9a78) at ../Viewer.cpp:544 #14 0x40e1ba0f in osg::GraphicsContext::runOperations (this=0x80f9a78) at ../GraphicsContext.cpp:426 #15 0x41707ca3 in ViewerRunOperations::operator() (this=0xf1fbba8, object=0x80f9a78) at ../Viewer.cpp:969 #16 0x40e21416 in osg::OperationsThread::run (this=0x91b7910) at ../GraphicsThread.cpp:290 #17 0x414528f5 in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib/libOpenThreads.so #18 0x414fdaa7 in start_thread () from /lib/tls/libpthread.so.0 #19 0x40b96c2e in clone () from /lib/tls/libc.so.6 -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463640 fax +49.8031.463645 email[EMAIL PROTECTED] internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
