[thread] understanding multiple statically-linked boost::thread in same process
hi boost users, i am debugging an application where several shared libraries contain statically-linked copies of boost::thread (and other boost components). this means the static part of boost::thread is multiple times present in the process. on macos (apple clang 7.3) we see rare (but reproducible) access violations caused by boost::thread_specific_ptr::get() unexpectedly returning nullptr. if we enable assertions we get an assert in thread.cpp:151 if we dynamically link boost the problems go away. i can superficially understand that linking only one "common" instance of boost::thread is "more safe". what could be the explanation for this observation? is this setup even supported? one theory is that the implementations in pthread/thread_heap_alloc.hpp interfere with each other... the specific line where we get an unexpected nullptr (actually a bad reference) is here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CGAL_cgal_blob_releases_CGAL-2D4.9_Filtered-5Fkernel_include_CGAL_Lazy.h-23L792&d=DwIFAw&c=n6-cguzQvX_tUIrZOS_4Og&r=gTL_yCLQl_7u2-yqgVXg0brOZdHvslFzcgXDiq_Zsb4&m=yj4lKAj11ftBa5Mw9t_dA9ja7LXtLliU9xCHesY3DhQ&s=59bluh0MtAaZJ3EXnqozwpQNY_re1ncp8Q559nsJYiw&e= the definition of CGAL_STATIC_THREAD_LOCAL_VARIABLE is here?: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_CGAL_cgal_blob_releases_CGAL-2D4.9_Installation_include_CGAL_tss.h-23L38&d=DwIFAw&c=n6-cguzQvX_tUIrZOS_4Og&r=gTL_yCLQl_7u2-yqgVXg0brOZdHvslFzcgXDiq_Zsb4&m=yj4lKAj11ftBa5Mw9t_dA9ja7LXtLliU9xCHesY3DhQ&s=yX1td4vN_WehQasy76CR80NEszc9YoFAwKDJ7EBdNcM&e= boost version is 1.59 TIA, simon -- Simon Haegler | Software Engineer Esri R&D Center Zurich | Foerrlibuckstrasse 110 | 8005 Zurich | Switzerland T +41 44 204 60 80 | shaegler@esri.com
i am debugging an application where several shared libraries contain statically-linked copies of boost::thread (and other boost components). this means the static part of boost::thread is multiple times present in the process.
Yeah, don't do that. Don't mix multiple copies of any Boost or STL or indeed any C++ library in the same process unless the library explicitly guarantees you are allowed to. If it doesn't say, then you're not allowed to.
if we dynamically link boost the problems go away. i can superficially understand that linking only one "common" instanceof boost::thread is "more safe".
Not "more safe". Just "safe".
what could be the explanation for this observation? is this setup even supported? one theory is that the implementations in pthread/thread_heap_alloc.hpp interfere with each other...
You can try raising it as a bug with Thread, but if I were still a maintainer there I'd close it immediately as wontfix invalid. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 28/01/2017 04:29, Simon Haegler wrote:
i am debugging an application where several shared libraries contain statically-linked copies of boost::thread (and other boost components). this means the static part of boost::thread is multiple times present in the process.
on macos (apple clang 7.3) we see rare (but reproducible) access violations caused by boost::thread_specific_ptr::get() unexpectedly returning nullptr. if we enable assertions we get an assert in thread.cpp:151
if we dynamically link boost the problems go away. i can superficially understand that linking only one "common" instanceof boost::thread is "more safe".
As Niall said, the general rules for library interaction are to not do that. You can sometimes get away with it if you're very careful about isolation -- in this case, it would probably work if you made sure that the thread_specific_ptrs are only ever accessed on threads that were started by the same library, and completely hid these threads from the consumers of the library -- but this way lies dragons, and it's far too easy to make seemingly simple changes that poke a hole in the isolation and break things, sometimes in subtle ways. So don't do it.
niall, gavin, thanks for your help. we successfully managed to eliminate the multiple copies of CGAL and boost::thread and the problem is gone. best, simon ________________________________________ From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of Gavin Lambert <gavinl@compacsort.com> Sent: Tuesday, January 31, 2017 00:19 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [thread] understanding multiple statically-linked boost::thread in same process On 28/01/2017 04:29, Simon Haegler wrote:
i am debugging an application where several shared libraries contain statically-linked copies of boost::thread (and other boost components). this means the static part of boost::thread is multiple times present in the process.
on macos (apple clang 7.3) we see rare (but reproducible) access violations caused by boost::thread_specific_ptr::get() unexpectedly returning nullptr. if we enable assertions we get an assert in thread.cpp:151
if we dynamically link boost the problems go away. i can superficially understand that linking only one "common" instanceof boost::thread is "more safe".
As Niall said, the general rules for library interaction are to not do that. You can sometimes get away with it if you're very careful about isolation -- in this case, it would probably work if you made sure that the thread_specific_ptrs are only ever accessed on threads that were started by the same library, and completely hid these threads from the consumers of the library -- but this way lies dragons, and it's far too easy to make seemingly simple changes that poke a hole in the isolation and break things, sometimes in subtle ways. So don't do it. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.boost.org_mailman_listinfo.cgi_boost-2Dusers&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=1qMgo39tVkx6cj8JVbCB5naHvVpKbYm8ncmOImpHPQY&m=t8Qx5jGJxvUNSoo53HQ3aW2Y8wpWRuwlLxye0SW6m9o&s=ILd1gLvij5UVuvlV9jPFNB3EY_CkzptDVgi_wfLpjJg&e=
participants (3)
-
Gavin Lambert -
Niall Douglas -
Simon Haegler