Hello Patrick,
Patrick Dähne wrote:
> Hello,
>
> after debugging my randomly crashing multithreaded OpenSG application
> for several hours, I've had to realize that the problem is actually
> the OSG::Log which to my big surprise is not thread-safe. Whenever you
> write something into the log, the method OSG::Log::doLog() gets
> called, which uses one single static buffer to assemble the message.
> This method is protected by OSG::lock() and OSG::unlock(). Both
> methods are not implemented and empty.
yes, that fact that we don't really have a lock in there is (well kind
of) known ;)
I was not aware that this could lead to problems other than garbled
output, but your are right of course, there is a race for growing that
static buffer.
> My naive idea now was to implement these methods by creating an
> OSG::Lock object. But to my surprise, that also crashed, because you
> can only create OSG::Lock objects after the OpenSG type system gets
> initialized, and OSG::Log gets created before the type system gets
> initialized.
yup, probably part of the reason these functions are empty ;)
> This problem exists in OpenSG 1 as well as OpenSG 2.
>
> So this leads me to the final conclusion: Despite the fact that a lot
> of effort has been made to make OpenSG thread-safe, and despite the
> fact that it is frequently claimed on the OpenSG mailing lists that
> OpenSG is especially dedicated to multithreaded applications, you
> cannot use OpenSG in a multithreaded environment because it may crash
> anytime when someone writes something into the log.
>
> That is not really a convincing situation. I think that should be
> fixed immediately. Unfortunately, I'm running out of ideas. What do
> other people think?
It should be fixed on cvs HEAD and svn trunk. I replaced the static
buffer on the heap with one on the stack. This has the slight
disadvantage that the log message length is limited (currently to 4096
characters), but I do not consider this to be a problem in practice. The
buffer is filled with vnsprintf when available, so overflow should not
be a problem and additionally a warning will be printed that the message
was truncated.
Hope it helps,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
