[Boost-users] [thread] understanding multiple statically-linked

[Simon Haegler]

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 [phone] | ***@esri.com

[Niall Douglas]

Post by Simon Haegler
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.

Post by Simon Haegler
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".

Post by Simon Haegler
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

[Gavin Lambert]

Post by Simon Haegler
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.

[Simon Haegler]

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-***@lists.boost.org> on behalf of Gavin Lambert <***@compacsort.com>
Sent: Tuesday, January 31, 2017 00:19
To: boost-***@lists.boost.org
Subject: Re: [Boost-users] [thread] understanding multiple statically-linked boost::thread in same process

Post by Simon Haegler
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.