[haiku-bugs] [Haiku] #11482: pthreads: possible race condition leading to deadlock
- From: "jessicah" <trac@xxxxxxxxxxxx>
- Date: Mon, 17 Nov 2014 05:12:49 -0000
#11482: pthreads: possible race condition leading to deadlock
-------------------------------+------------------------------
Reporter: jessicah | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/libroot.so | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
-------------------------------+------------------------------
I'm working on upstreaming Haiku support for Boost, and am running into a
reproducible deadlock for the Boost.Interprocess module.
My current work can be found at https://github.com/jessicah/boost
I think `git clone --recursive https://github.com/jessicah/boost.git`
should do the right thing. Else you'll also need to grab the build,
config, predef, thread, filesystem, and interprocess submodules from my
GitHub as well.
Steps to reproduce:
{{{
./bootstrap.sh
./b2 --without-mpi --enable-parallel-mark inlining=on threading=multi
variant=debug link=static,shared runtime-link=shared --without-python
-j<N>
cd libs/interprocess
../../b2 --without-mpi --enable-parallel-mark inlining=on threading=multi
variant=debug link=static,shared runtime-link=shared --without-python
-j<N> -a -q test
}}}
Eventually, several tests will end up deadlocked, these are
`condition_test`, `condition_any_test`, `named_condition_test`, and
`named_condition_any_test`.
If I attach Debugger to any of these tests, I can break the deadlock by
debugging all currently running threads, then resuming the test thread
(this has the `pthread_join` call in the stack trace), then resuming the
other threads. If I instead resume the other threads first, the deadlock
remains.
The named tests sometimes require repeating the process, but will
eventually resume.
--
Ticket URL: <https://dev.haiku-os.org/ticket/11482>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
