Thanks Peter Dimov, i have added logic unlock in signal handler, now i am
not seeing this issue.
I am seeing one more issue, if i call construct object and do work and
clear in loop of ~30000, i see following error while construct call.
43 #0 set_bits (b=0, n=...) at /x86/include/boost/interp
rocess/offset_ptr.hpp:728
44 #1 set_color (c=<optimized out>, n=...) at /x86/inclu
de/boost/intrusive/detail/rbtree_node.hpp:167
45 #2
boost::intrusive::rbtree_algorithms, true> >::rebalance_after_insertion
(header=..., p=...) at
/x86/include/boost/intrusive/rbtree_algorithms.hpp:558
46 #3 0x0000000001c3ba5d in
insert_equalboost::interprocess::mutex_family::block_ctrl>,
boost::intrusive::bhtraits::block_ctrl,
boost::intrusive::rbtree_node_traits, (boost::intrusive::link_mode_type)0, boost::intrusive::dft_tag,
3u>, boost::move_detail::identityboost::interprocess::mutex_family::block_ctrl> > > (comp=...,
new_node=..., hint=..., header=...) at
/x86/include/boost/intrusive/rbtree_algorithms.hpp:388
47 #4
boost::intrusive::bstree_impl,
0ul>::block_ctrl, boost::intrusive::rbtree_node_tr
aits,
true>, (boost::intrusive::link_mode_type)0, boost::int rusive::dft_tag,
3u>, void, void, unsigned long, true, (boost::intrusive::algo_types)5,
void>::insert_equal (this=this@entry =0x7fcdf86f5038, hint=...,
value=...) at /x86/include/ boost/intrusive/bstree.hpp:1085
48 #5 0x0000000001c3e9f5 in insert (value=..., hint=...,
this=0x7fcdf86f5038) at /x86/include/boost/intrusive/set.hpp:752
49 #6
boost::interprocess::rbtree_best_fit,
0ul>::priv_check_and_allocate (this=this@entry=0x7fcdf86f5010,
nunits=nunits@entry=10, block=0x7fcdf87429c0 ,
received_size=@0x7fcdfb5f5730: 149) at /x86/include/
boost/interprocess/mem_algo/rbtree_best_fit.hpp:1282
50 #7 0x0000000001c4c7ac in priv_allocate (backwards_multiple=1,
reuse_ptr=<synthetic pointer>, prefer_in_recvd_out_size=@0x7f
cdfb5f5730: 149, limit_size=<optimized out>, command=1,
this=0x7fcdf86f5010) at
/x86/include/boost/interprocess/mem_algo/rbtree_best_fit.hpp:977
51 #8
boost::interprocess::rbtree_best_fit,
0ul>::allocate (this=this@entry=0x7fcdf86f5010, nbytes=<optimized out>) at
/x86/include/boost/interprocess/mem_algo/rbtree_best_fit.hpp:673
52 #9 0x0000000001c4cc85 in allocate (nbytes=<optimized out>,
this=0x7fcdf86f5010) at
/x86/include/boost/interprocess/segment_manager.hpp:177
let me know what can cause this kind of issue.
Regards,
Murali
On Thu, Jan 23, 2025 at 11:35 PM Peter Dimov wrote:
Murali Kishore wrote:
Hi ,
We are trying interprocess scenario, one process created shared memory
objects and killed and second process open the object using
find_or_construct
seeing this process blocked at getting lock.
bt as shown below,
#0 __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007fa6b6733eb6 in _L_lock_941 () from /lib64/libpthread.so.0
#2 0x00007fa6b6733daf in __GI___pthread_mutex_lock
(mutex=mutex@entry=0x7fa6b198b070)
at ../nptl/pthread_mutex_lock.c:113
#3 0x0000000001bc3822 in lock (this=0x7fa6b198b070) at
/x86/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90
Detecting mutexes held by dead processes requires the so-called
POSIX robust mutexes. I can see in the Interprocess source code
that those are enabled when the macro
BOOST_INTERPROCESS_POSIX_ROBUST_MUTEXES is defined.
This macro is defined automatically
#if (_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L)
https://github.com/boostorg/interprocess/blob/29cee9c6067f1d20ddb6421af15977...
but I suppose you can also try defining it manually and see if that helps,
because _XOPEN_SOURCE and _POSIX_C_SOURCE are also user macros
and you probably aren't defining any of them.
--
Regards,
Murali Kishore
