[osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
acoates at stanford.edu
Tue Sep 25 12:10:56 PDT 2007
That looks like it'll do the trick -- and valgrind now gives a clean
report as far as memory accesses (because the lock is now safe to
access). One last thing: you might look into the memory leak issue
reported from pthread_create; see my replies there for the issue.
On 9/25/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> Hi Adamn,
> On 9/25/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> > On 9/24/07, Adam Coates <acoates at stanford.edu> wrote:
> > > It looks like there's still a problem with the current setup. The
> > > Thread object itself can get deleted before the pthread actually gets
> > > to the lock (which, I guess is what you just added).
> I have modified osgunittests so it now has a function that tests the
> creation, start and deletion of a thread, as per code example, you can
> run it via:
> osgunittests thread
> With the yesterdays code it worked fine on my system about 2/3rd of
> the times that it was run, more if I didn't add the delay (this is now
> a Thread::microSleep). The tests I did yesterday were done without
> the delay which is probably why I didn't see any crashes after my
> first round of fixes yesterday.
> Armed with a relatively reliable means for recreating the crash I've
> now set about refactoring the OpenThreads::Thread code so that instead
> of using a mutex in the start method and destructor it uses a
> OpenThreads::Block in the Thread::start() method and static
> StartThread() function such that the thread that calls the
> thread->startThread() will be held back until the new thread has been
> successfully started. With this change I'm now able to run the
> osgunittest thread test 1000 times without error (I use a repeat
> script to do this).
> I have also rolled these changes into Windows and IRIX spoc code
> paths, revert the previous Mutex based code.
> Could you check out the latest version in SVN and let me know if this
> problem is now properly fixed.
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users