Re: [lockfree][Interprocess] - SPSC queue in shared memory cause SEG fault

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2019-10-23 09:33:04

On Tue, 22 Oct 2019, 07:05 Saravanan A via Boost, <boost_at_[hidden]>
wrote:

> Hi Team,
>
>                 We Currently trying to develop a  prototype with boost
> libraries, where we are facing an issue in it with boost library. It would
> be great if someone help out here   .
>
>
>
> we are having  two process where one process create “*managed xsi shared
> memory”* and other get attached to it. Here we trying  to have a spsc queue
> in a shared memory structure which will be accessed by both process . Where
> SPSC queue data is a user defined class object.  when we have a integer in
> ”
> *Mydata”* (Class name) mentioned below and try to do a  Push /pop operation
> in  the spsc  queue on respective  process it was working fine without any
> issues. But the same framework when we have an array of greater size(more
> than 28 byte around. Example: a[7] ) .We are facing a crash in consumer
> side .
>
>
>
> (It seems spsc queue write somewhere in process heap memory after first pop
> leading  to memory corrupt )
>
>
>
> please let us know if  there any open issue in this ? or if we have used
> boost library incorrectly ? Thanks for reading. I would be thankful for any
> information you may have to offer.
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Backtrace:*
>
>
>
> /data/users/kapparao/example_boost/anony-SHM-managed> $./processB
>
> Consumer-TX - Read data from Q - [1,b]
>
> notify_one_at_93 - I am here!
>
> notify_one_at_159 - I am here!
>
> Segmentation fault (core dumped)
>
> /data/users/kapparao/example_boost/anony-SHM-managed> $gdb ./processB
>
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7
>
> Copyright (C) 2013 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html
> >
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "x86_64-redhat-linux-gnu".
>
> For bug reporting instructions, please see:
>
> <http://www.gnu.org/software/gdb/bugs/>...
>
> Reading symbols from
> /data/users/kapparao/example_boost/anony-SHM-managed/processB...done.
>
> (gdb) r
>
> Starting program:
> /data/users/kapparao/example_boost/anony-SHM-managed/./processB
>
> [Thread debugging using libthread_db enabled]
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Consumer-TX - Read data from Q - [1,b]
>
>
>
> Program received signal SIGSEGV, Segmentation fault.
>
> 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
>
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.17-292.0.1.el7.x86_64 libgcc-4.8.5-39.0.1.el7.x86_64
> libstdc++-4.8.5-39.0.1.el7.x86_64
>
> (gdb) bt
>
> #0  0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
>
> #1  0x00000000004063de in
> boost::interprocess::ipcdetail::posix_condition::notify_one (this=0x28) at
> ../../boost/include/boost/interprocess/sync/posix/condition.hpp:160
>
> #2  0x00000000004066e1 in
> boost::interprocess::interprocess_condition::notify_one (this=0x28) at
> ../../boost/include/boost/interprocess/sync/interprocess_condition.hpp:94
>
> #3  0x0000000000402941 in main () at processB.cpp:42
>
>
>
>
>
>
>
> Attached the complete code in tar for your reference.
>
>
>
> *Compilation and  Execution* :
>
>
>
> *Process A : *
>
> Compilation syntax  :
>
> c++ my_data.cc processA.cpp -I < boost_header_file_path>
> <boost_lib_path>   -lpthread -g -o processA -std=c++11
>
> Execution syntax :
>
> ./processA
>
>
>
> *Process B :*
>
> Compilation syntax  :
>
> c++ my_data.cc processB.cpp -I < boost_header_file_path>
> <boost_lib_path>   -lpthread -g -o processB -std=c++11
>
> Execution syntax :
>
> ./processB
>
>
>
> *Thanks in advance !!!!
>

lockfree spsc does not support being mapped in two different processes at
different locations.
This could be implemented as an extension.

Also you're using locks with a lockfree queue, that makes no sense at all.
Either use a normal queue with locks or don't use locks.