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
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 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/
