Boost C++ Libraries: Ticket #9466: shared_ptr fails with EINVAL on AIX 7.1 when compiled with atomic

Peter Dimov — Tue, 03 Dec 2013 16:25:56 GMT

Interesting. I can't think of a mechanism by which libboost_atomic could cause shared_ptr to fail in such a manner. Furthermore, on AIX shared_ptr doesn't use pthread_mutex by default:

#elif defined( _AIX )
# include <boost/smart_ptr/detail/sp_counted_base_aix.hpp>

Trying to lock an invalid mutex can be a symptom of an ODR violation. If some .cpp files are compiled with BOOST_SP_USE_PTHREADS and some others aren't, it's possible for a .cpp file in the first group to try to lock a pthread_mutex which doesn't exist because a shared_ptr created by a .cpp file in the second group doesn't have it.

anonymous — Tue, 03 Dec 2013 17:24:40 GMT

hmm, i,m not really convinced. If I build the boostlibs on aix or e.g. linux, using the same bootstrap params then clearly only on aix the atomic lib is build, and needs to be linked. Thats not the case on linux.

Futhermore for debuggung purposes I added some stdout logging inside the lwm_pthread.hpp. On linux that filw was not used, however on aix is is, thats where i notice the EINVAL(22) return value.

If however on aix I specify the BOOST_THREAD_DONT_USE_ATOMIC, than it wont be using lwm_pthead.hpp. In which case the behaviour is identical to the linux build.

I can provide some logging to tomorrow if you need it?

Regards, -- Pat --

Peter Dimov — Tue, 03 Dec 2013 21:31:08 GMT

The Boost.Atomic library is apparently used by Boost.Thread in its implementation of call_once, which is why it probably needs to be linked. But it's not used by shared_ptr. You will need to identify what calls into lwm_pthread.hpp, because shared_ptr is not the only component that uses it. Can you provide a stack trace?

attachment set

Wed, 04 Dec 2013 12:20:34 GMT

attachment → readme

attachment set

Wed, 04 Dec 2013 12:24:55 GMT

attachment → build-boost-aix71-12583090-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:25:08 GMT

attachment → build-boost-aix71-15663342-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:25:24 GMT

attachment → build-boost_x86_64-pc-linux-rhel6-gnu-64-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:25:36 GMT

attachment → build-ilona-aix71-11796734-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:25:47 GMT

attachment → build-ilona-aix71-16121982-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:26:00 GMT

attachment → build-ilona_x86_64-pc-linux-rhel6-gnu-64-debug.log.tar.gz

attachment set

Wed, 04 Dec 2013 12:26:11 GMT

attachment → callstack.log

Wed, 04 Dec 2013 12:28:44 GMT

Okay, check the provided attachments (I had to compress due to upload size limits). The readme file explains what we did, and refers to the various log files.

Regards, -- Pat --

anonymous — Wed, 04 Dec 2013 12:40:43 GMT

Does ilona use boost::call_once before main, that is, in a static constructor?

Wed, 04 Dec 2013 13:21:20 GMT

no we don't use the call_once ...

Peter Dimov — Wed, 04 Dec 2013 14:17:40 GMT

As far as I can see, BOOST_THREAD_DONT_USE_ATOMIC only affects boost::call_once, forcing it to not use Boost.Atomic. So something must be using call_once. It's possible that some Boost library is using it internally.

What I think happens is the following. Boost.Atomic, under AIX, falls back to its generic lock pool implementation in boost/atomic/detail/lockpool.hpp and libs/atomic/src/lockpool.cpp. This uses boost::lightweight_mutex, and consequently lwm_pthreads.hpp.

The mutex pool (a static array of 41 lightweight_mutex objects) is defined in libs/atomic/src/lockpool.cpp. However, since lightweight_mutex has a constructor calling pthread_mutex_init and a destructor calling pthread_mutex_destroy, it is possible for call_once to end up using this mutex pool before it's constructed or after it's destroyed, depending on static initialization order.

If I'm correct in this assumption, then your workaround of defining BOOST_THREAD_DONT_USE_ATOMIC is the right one for now. We'll see how we can fix the problem on our side.

owner changed

Peter Dimov — Wed, 04 Dec 2013 14:19:08 GMT

owner changed from Peter Dimov to viboes

Vicente, do you have any ideas? Does my analysis appear correct?

cc set

Andrey Semashev — Wed, 04 Dec 2013 15:03:09 GMT

cc Andrey.Semashev@… added

Andrey Semashev — Wed, 04 Dec 2013 15:16:40 GMT

Peter, you are correct that in case if lock pool is used in Boost.Atomic it cannot be safely used in global initializers. I'd like to fix that.

owner changed

Peter Dimov — Wed, 04 Dec 2013 15:20:31 GMT

owner changed from viboes to Andrey Semashev

component changed

Peter Dimov — Wed, 04 Dec 2013 15:42:35 GMT

component smart_ptr → atomic

Andrey Semashev — Sat, 14 Dec 2013 15:47:29 GMT

Should be fixed in git: https://github.com/boostorg/atomic/commit/9ded906200ea83ceb24b1be007ed14da262e5ea0. Please, try if it helps.

status changed; resolution set

Andrey Semashev — Tue, 07 Jan 2014 11:37:54 GMT

status new → closed
resolution → fixed

Merged to master in https://github.com/boostorg/atomic/commit/1fc5d75a980143e5f43f94df45efa419e73e88f1.