[asio-users] Segmentation fault.

[Slav]

Hello.
I have segmentation fault happening once per ~week server's work when he
process already several million players. GCC points to line with closing
round bracket of block
__asm__ __volatile__
(
"lock\n\t"
"xadd %1, %0":
"+m"( *pw ), "=r"( r ): // outputs (%0, %1)
"1"( dv ): // inputs (%2 == %1)
"memory", "cc" // clobbers
); <-------- GCC points here
at file /usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67

I didn't came to the problem deeper (it's first time I can examine the
stack) - it's 3 o`clock now, but I am curious why there is "x86" postfix if
I have x64 architecture:
Linux version 3.2.0-26-generic (***@batsu) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) )
Ubuntu 12.04 LTS \n \l
Intex Xeon CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Stepping: 9
CPU MHz: 1600.000
BogoMIPS: 6584.73
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Boost version "1.46.1". I use Asio from CVS repository, updated couple of
weeks ago.

Is there a way just somehow to mute this problem at least, if it cannot be
resolved? This problem happens very rarely and I don't care if it even
killes/malfunctions/occupies thread/connection or something - it's need
just to keep server working.

Thank you.

Whole callstack is so:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffecb7fe700 (LWP 23732)]
0x000000000043a1a3 in boost::detail::atomic_count::atomic_exchange_and_add
(pw=0xf0, dv=1) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67
67 );
(gdb) backtrace
#0 0x000000000043a1a3 in
boost::detail::atomic_count::atomic_exchange_and_add (pw=0xf0, dv=1) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67
#1 0x000000000043a141 in boost::detail::atomic_count::operator++
(this=0xf0) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:30
#2 0x000000000043b910 in asio::detail::task_io_service::work_started
(this=0x84) at
/home/slav/programs/asio/asio/include/asio/detail/task_io_service.hpp:75
#3 0x000000000043d692 in
asio::detail::task_io_service::post_immediate_completion (this=0x84,
op=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.ipp:204
#4 0x000000000043be69 in
asio::detail::epoll_reactor::post_immediate_completion
(this=0x7ffef46cfeb0, op=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/epoll_reactor.hpp:82
#5 0x000000000043c683 in asio::detail::epoll_reactor::start_op
(this=0x7ffef46cfeb0, op_type=1, descriptor=-201324776,
descriptor_data=@0x7ffef518e570: 0x7ffef518e550,
op=0x7ffef40cb0a0, allow_speculative=true) at
/home/slav/programs/asio/asio/include/asio/detail/impl/epoll_reactor.ipp:132
#6 0x000000000043f6f1 in
asio::detail::reactive_socket_service_base::start_op (this=0x7ffef40000a0,
impl=..., op_type=1, op=0x7ffef40cb0a0, non_blocking=true, noop=false)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/reactive_socket_service_base.ipp:160
#7 0x000000000047e82c in
asio::detail::reactive_socket_service_base::async_send<asio::const_buffers_1,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp, asio::str
eam_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio, fos::ClientsH
andler_Asio::Client*, fos::SentData*, asio::error_code const&, unsigned
long>, boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHand
ler_Asio::Client*>, boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(),
boost::arg<2> (*)()> > > > (this=0x7ffef40000a0, impl=..., buffers=...,
flags=0, handler=...)
at
/home/slav/programs/asio/asio/include/asio/detail/reactive_socket_service_base.hpp:199
#8 0x000000000047a0ab in
asio::stream_socket_service<asio::ip::tcp>::async_send<asio::const_buffers_1,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp, asio::str
eam_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio, fos::ClientsH
andler_Asio::Client*, fos::SentData*, asio::error_code const&, unsigned
long>, boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHand
ler_Asio::Client*>, boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(),
boost::arg<2> (*)()> > > > (this=0x7ffef4000078, impl=..., buffers=...,
flags=0, handler=...)
at
/home/slav/programs/asio/asio/include/asio/stream_socket_service.hpp:283
#9 0x00000000004711e2 in asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp>
>::async_write_some<asio::const_buffers_1, asio::detail::write_op<a
sio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::
mf4<void, fos::ClientsHandler_Asio, fos::ClientsHandler_Asio::Client*,
fos::SentData*, asio::error_code const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsH
andler_Asio*>, boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > > (this=0x7ffef518e560,
buffers=..., handler=...) at
/home/slav/programs/asio/asio/include/asio/basic_stream_socket.hpp:607
#10 0x0000000000460b0c in
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::tran
sfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf4<void,
fos::ClientsHandler_Asio, fos::ClientsHandler_Asio::Client*,
fos::SentData*, asio::error_code const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), bo
ost::arg<2> (*)()> > >::operator() (this=0x7ffecb7fd790, ec=...,
bytes_transferred=8760, start=0) at
/home/slav/programs/asio/asio/include/asio/impl/write.hpp:256
#11 0x0000000000486674 in
asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers
_1, asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code c
onst&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, b
oost::arg<1> (*)(), boost::arg<2> (*)()> > >, asio::error_code, unsigned
long>::operator() (this=0x7ffecb7fd790)
at /home/slav/programs/asio/asio/include/asio/detail/bind_handler.hpp:96
#12 0x00000000004865e4 in
asio::asio_handler_invoke<asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::t
cp> >, asio::const_buffers_1, asio::detail::transfer_all_t,
boost::_bi::bind_t<void, boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long> > (function=...)
at /home/slav/programs/asio/asio/include/asio/handler_invoke_hook.hpp:63
#13 0x000000000048611b in
asio_handler_invoke_helpers::invoke<asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > (function=..., context=...)
at
/home/slav/programs/asio/asio/include/asio/detail/handler_invoke_helpers.hpp:39
#14 0x00000000004856af in
asio::detail::asio_handler_invoke<asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>,
asio::basic_stream_socket<asio::ip::tcp, asio::stream_socket_se---Type
<return> to continue, or q <return> to quit---
rvice<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > (function=..., this_handler=0x7ffecb7fd880)
at /home/slav/programs/asio/asio/include/asio/impl/write.hpp:304
#15 0x0000000000484954 in
asio_handler_invoke_helpers::invoke<asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > > (function=..., context=...)
at
/home/slav/programs/asio/asio/include/asio/detail/handler_invoke_helpers.hpp:39
#16 0x00000000004834bb in
asio::detail::reactive_socket_send_op<asio::const_buffers_1,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code const&,
unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > >::do_complete (owner=0xa71cb0, base=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/reactive_socket_send_op.hpp:102
#17 0x000000000043b87b in asio::detail::task_io_service_operation::complete
(this=0x7ffef40cb0a0, owner=...)
at
/home/slav/programs/asio/asio/include/asio/detail/task_io_service_operation.hpp:34
#18 0x000000000043d9f9 in asio::detail::task_io_service::do_one
(this=0xa71cb0, lock=..., this_idle_thread=0x7ffecb7fda40)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.ipp:277
#19 0x000000000043d554 in asio::detail::task_io_service::run
(this=0xa71cb0, ec=...) at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.ipp:129
#20 0x000000000043dd91 in asio::io_service::run (this=0xa71be8) at
/home/slav/programs/asio/asio/include/asio/impl/io_service.ipp:56
#21 0x0000000000424062 in fos::ClientsHandler_Asio::Run (this=0xa71be0) at
../../fos/src/handlers/asio/clients_handler_asio.cpp:111
#22 0x0000000000481755 in boost::_mfi::mf0<void,
fos::ClientsHandler_Asio>::operator() (this=0xa746b8, p=0xa71be0) at
/usr/include/boost/bind/mem_fn_template.hpp:49
#23 0x000000000047ecd6 in
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*>
>::operator()<boost::_mfi::mf0<void, fos::ClientsHandler_Asio>,
boost::_bi::list0> (
this=0xa746c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:253
#24 0x000000000047a309 in boost::_bi::bind_t<void, boost::_mfi::mf0<void,
fos::ClientsHandler_Asio>,
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*> >
>::operator() (this=0xa746b8) at
/usr/include/boost/bind/bind_template.hpp:20
#25 0x0000000000487d74 in
boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void,
fos::ClientsHandler_Asio>,
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*> > > >::run
(this=0xa74530) at /usr/include/boost/thread/detail/thread.hpp:61
#26 0x00007ffff7bcdce9 in thread_proxy () from
/usr/lib/libboost_thread.so.1.46.1
#27 0x00007ffff5eabe9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#28 0x00007ffff61b34bd in clone () from /lib/x86_64-linux-gnu/libc.so.6

[Gruenke, Matt]

I suspect you might be accessing an object after it's been deallocated.
Have you tried running your program under valgrind? It can find memory
bugs (double-frees, accesses of uninitialized memory, memory leaks,
bounds overruns, etc.) and supposedly even race conditions (though I've
never used that tool). Beware that it does slow down CPU-bound code by
about 10x.



Generally speaking, you need to think carefully about object lifetime &
ownership. These are some of the most difficult aspects of using
Boost.Asio.



Good luck!





Matt





From: Slav [mailto:***@gmail.com]
Sent: Monday, August 06, 2012 7:02 PM
To: asio-***@lists.sourceforge.net
Subject: [asio-users] Segmentation fault.



Hello.
I have segmentation fault happening once per ~week server's work when he
process already several million players. GCC points to line with closing
round bracket of block
__asm__ __volatile__
(
"lock\n\t"
"xadd %1, %0":
"+m"( *pw ), "=r"( r ): // outputs (%0, %1)
"1"( dv ): // inputs (%2 == %1)
"memory", "cc" // clobbers
); <-------- GCC points here
at file /usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67

I didn't came to the problem deeper (it's first time I can examine the
stack) - it's 3 o`clock now, but I am curious why there is "x86" postfix
if I have x64 architecture:
Linux version 3.2.0-26-generic (***@batsu) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) )
Ubuntu 12.04 LTS \n \l
Intex Xeon CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Stepping: 9
CPU MHz: 1600.000
BogoMIPS: 6584.73
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Boost version "1.46.1". I use Asio from CVS repository, updated couple
of weeks ago.

Is there a way just somehow to mute this problem at least, if it cannot
be resolved? This problem happens very rarely and I don't care if it
even killes/malfunctions/occupies thread/connection or something - it's
need just to keep server working.

Thank you.

Whole callstack is so:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffecb7fe700 (LWP 23732)]
0x000000000043a1a3 in
boost::detail::atomic_count::atomic_exchange_and_add (pw=0xf0, dv=1) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67
67 );
(gdb) backtrace
#0 0x000000000043a1a3 in
boost::detail::atomic_count::atomic_exchange_and_add (pw=0xf0, dv=1) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:67
#1 0x000000000043a141 in boost::detail::atomic_count::operator++
(this=0xf0) at
/usr/include/boost/smart_ptr/detail/atomic_count_gcc_x86.hpp:30
#2 0x000000000043b910 in asio::detail::task_io_service::work_started
(this=0x84) at
/home/slav/programs/asio/asio/include/asio/detail/task_io_service.hpp:75
#3 0x000000000043d692 in
asio::detail::task_io_service::post_immediate_completion (this=0x84,
op=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.i
pp:204
#4 0x000000000043be69 in
asio::detail::epoll_reactor::post_immediate_completion
(this=0x7ffef46cfeb0, op=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/epoll_reactor.hpp:82
#5 0x000000000043c683 in asio::detail::epoll_reactor::start_op
(this=0x7ffef46cfeb0, op_type=1, descriptor=-201324776,
descriptor_data=@0x7ffef518e570: 0x7ffef518e550,
op=0x7ffef40cb0a0, allow_speculative=true) at
/home/slav/programs/asio/asio/include/asio/detail/impl/epoll_reactor.ipp
:132
#6 0x000000000043f6f1 in
asio::detail::reactive_socket_service_base::start_op
(this=0x7ffef40000a0, impl=..., op_type=1, op=0x7ffef40cb0a0,
non_blocking=true, noop=false)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/reactive_socket_s
ervice_base.ipp:160
#7 0x000000000047e82c in
asio::detail::reactive_socket_service_base::async_send<asio::const_buffe
rs_1, asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::str
eam_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio, fos::ClientsH
andler_Asio::Client*, fos::SentData*, asio::error_code const&, unsigned
long>, boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHand
ler_Asio::Client*>, boost::_bi::value<fos::SentData*>, boost::arg<1>
(*)(), boost::arg<2> (*)()> > > > (this=0x7ffef40000a0, impl=...,
buffers=..., flags=0, handler=...)
at
/home/slav/programs/asio/asio/include/asio/detail/reactive_socket_servic
e_base.hpp:199
#8 0x000000000047a0ab in
asio::stream_socket_service<asio::ip::tcp>::async_send<asio::const_buffe
rs_1, asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::str
eam_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio, fos::ClientsH
andler_Asio::Client*, fos::SentData*, asio::error_code const&, unsigned
long>, boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHand
ler_Asio::Client*>, boost::_bi::value<fos::SentData*>, boost::arg<1>
(*)(), boost::arg<2> (*)()> > > > (this=0x7ffef4000078, impl=...,
buffers=..., flags=0, handler=...)
at
/home/slav/programs/asio/asio/include/asio/stream_socket_service.hpp:283
#9 0x00000000004711e2 in asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp>
>::async_write_some<asio::const_buffers_1, asio::detail::write_op<a
sio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::
mf4<void, fos::ClientsHandler_Asio, fos::ClientsHandler_Asio::Client*,
fos::SentData*, asio::error_code const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsH
andler_Asio*>, boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > > (this=0x7ffef518e560,
buffers=..., handler=...) at
/home/slav/programs/asio/asio/include/asio/basic_stream_socket.hpp:607
#10 0x0000000000460b0c in
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::tran
sfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf4<void,
fos::ClientsHandler_Asio, fos::ClientsHandler_Asio::Client*,
fos::SentData*, asio::error_code const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), bo
ost::arg<2> (*)()> > >::operator() (this=0x7ffecb7fd790, ec=...,
bytes_transferred=8760, start=0) at
/home/slav/programs/asio/asio/include/asio/impl/write.hpp:256
#11 0x0000000000486674 in
asio::detail::binder2<asio::detail::write_op<asio::basic_stream_socket<a
sio::ip::tcp, asio::stream_socket_service<asio::ip::tcp> >,
asio::const_buffers
_1, asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code c
onst&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, b
oost::arg<1> (*)(), boost::arg<2> (*)()> > >, asio::error_code, unsigned
long>::operator() (this=0x7ffecb7fd790)
at
/home/slav/programs/asio/asio/include/asio/detail/bind_handler.hpp:96
#12 0x00000000004865e4 in
asio::asio_handler_invoke<asio::detail::binder2<asio::detail::write_op<a
sio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::t
cp> >, asio::const_buffers_1, asio::detail::transfer_all_t,
boost::_bi::bind_t<void, boost::_mfi::mf4<void,
fos::ClientsHandler_Asio, fos::ClientsHandler_Asio::Client*,
fos::SentData*, asio::error_code const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long> > (function=...)
at
/home/slav/programs/asio/asio/include/asio/handler_invoke_hook.hpp:63
#13 0x000000000048611b in
asio_handler_invoke_helpers::invoke<asio::detail::binder2<asio::detail::
write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > (function=..., context=...)
at
/home/slav/programs/asio/asio/include/asio/detail/handler_invoke_helpers
.hpp:39
#14 0x00000000004856af in
asio::detail::asio_handler_invoke<asio::detail::binder2<asio::detail::wr
ite_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>,
asio::basic_stream_socket<asio::ip::tcp, asio::stream_socket_se---Type
<return> to continue, or q <return> to quit---
rvice<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > (function=..., this_handler=0x7ffecb7fd880)
at /home/slav/programs/asio/asio/include/asio/impl/write.hpp:304
#15 0x0000000000484954 in
asio_handler_invoke_helpers::invoke<asio::detail::binder2<asio::detail::
write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > >, asio::error_code, unsigned long>,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > > (function=..., context=...)
at
/home/slav/programs/asio/asio/include/asio/detail/handler_invoke_helpers
.hpp:39
#16 0x00000000004834bb in
asio::detail::reactive_socket_send_op<asio::const_buffers_1,
asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp,
asio::stream_socket_service<asio::ip::tcp> >, asio::const_buffers_1,
asio::detail::transfer_all_t, boost::_bi::bind_t<void,
boost::_mfi::mf4<void, fos::ClientsHandler_Asio,
fos::ClientsHandler_Asio::Client*, fos::SentData*, asio::error_code
const&, unsigned long>,
boost::_bi::list5<boost::_bi::value<fos::ClientsHandler_Asio*>,
boost::_bi::value<fos::ClientsHandler_Asio::Client*>,
boost::_bi::value<fos::SentData*>, boost::arg<1> (*)(), boost::arg<2>
(*)()> > > >::do_complete (owner=0xa71cb0, base=0x7ffef40cb0a0)
at
/home/slav/programs/asio/asio/include/asio/detail/reactive_socket_send_o
p.hpp:102
#17 0x000000000043b87b in
asio::detail::task_io_service_operation::complete (this=0x7ffef40cb0a0,
owner=...)
at
/home/slav/programs/asio/asio/include/asio/detail/task_io_service_operat
ion.hpp:34
#18 0x000000000043d9f9 in asio::detail::task_io_service::do_one
(this=0xa71cb0, lock=..., this_idle_thread=0x7ffecb7fda40)
at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.i
pp:277
#19 0x000000000043d554 in asio::detail::task_io_service::run
(this=0xa71cb0, ec=...) at
/home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.i
pp:129
#20 0x000000000043dd91 in asio::io_service::run (this=0xa71be8) at
/home/slav/programs/asio/asio/include/asio/impl/io_service.ipp:56
#21 0x0000000000424062 in fos::ClientsHandler_Asio::Run (this=0xa71be0)
at ../../fos/src/handlers/asio/clients_handler_asio.cpp:111
#22 0x0000000000481755 in boost::_mfi::mf0<void,
fos::ClientsHandler_Asio>::operator() (this=0xa746b8, p=0xa71be0) at
/usr/include/boost/bind/mem_fn_template.hpp:49
#23 0x000000000047ecd6 in
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*>
>::operator()<boost::_mfi::mf0<void, fos::ClientsHandler_Asio>,
boost::_bi::list0> (
this=0xa746c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:253
#24 0x000000000047a309 in boost::_bi::bind_t<void,
boost::_mfi::mf0<void, fos::ClientsHandler_Asio>,
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*> >
>::operator() (this=0xa746b8) at
/usr/include/boost/bind/bind_template.hpp:20
#25 0x0000000000487d74 in
boost::detail::thread_data<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, fos::ClientsHandler_Asio>,
boost::_bi::list1<boost::_bi::value<fos::ClientsHandler_Asio*> > >
>::run (this=0xa74530) at /usr/include/boost/thread/detail/thread.hpp:61
#26 0x00007ffff7bcdce9 in thread_proxy () from
/usr/lib/libboost_thread.so.1.46.1
#27 0x00007ffff5eabe9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#28 0x00007ffff61b34bd in clone () from /lib/x86_64-linux-gnu/libc.so.6

[Christof Meerwald]

On Tue, 7 Aug 2012 02:01:46 +0300, Slav wrote:
[...]
> Whole callstack is so:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffecb7fe700 (LWP 23732)]
[...]
> #3 0x000000000043d692 in
> asio::detail::task_io_service::post_immediate_completion (this=0x84,

that "this" pointer is invalid.

> op=0x7ffef40cb0a0)
> at
> /home/slav/programs/asio/asio/include/asio/detail/impl/task_io_service.ipp:204
> #4 0x000000000043be69 in
> asio::detail::epoll_reactor::post_immediate_completion
> (this=0x7ffef46cfeb0, op=0x7ffef40cb0a0)
> at
> /home/slav/programs/asio/asio/include/asio/detail/epoll_reactor.hpp:82
> #5 0x000000000043c683 in asio::detail::epoll_reactor::start_op
> (this=0x7ffef46cfeb0, op_type=1, descriptor=-201324776,

and that descriptor value also looks invalid (btw, op_type=1 would be
write_op)

> descriptor_data=@0x7ffef518e570: 0x7ffef518e550,
> op=0x7ffef40cb0a0, allow_speculative=true) at
> /home/slav/programs/asio/asio/include/asio/detail/impl/epoll_reactor.ipp:132

So looks like some kind of memory corruption. Maybe you just need to
review how you manage the lifetime of your socket objects.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[vmf229]

> [Switching to Thread 0x7ffecb7fe700 (LWP 23732)]

23732 is a big number. How many threads have you got?

[Slav]

I have thread pool with something like 100 threads for game logic,
PostgreSQL client, asio with ~3000 online connections and multiple curl
requests among different threads. But I don't think it can grow to 23732
threads...

2012/8/15 vmf229 <***@hotmail.com>

> > [Switching to Thread 0x7ffecb7fe700 (LWP 23732)]
>
> 23732 is a big number. How many threads have you got?
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>

[Gruenke, Matt]

LWPs aren't scoped by process. The number is largely irrelevant, unless
you also know what else has been running on the system and how long it's
been booted.





Matt





From: Slav
Sent: Wednesday, August 15, 2012 11:34 AM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Segmentation fault.



I have thread pool with something like 100 threads for game logic,
PostgreSQL client, asio with ~3000 online connections and multiple curl
requests among different threads. But I don't think it can grow to 23732
threads...

2012/8/15 vmf229

> [Switching to Thread 0x7ffecb7fe700 (LWP 23732)]

23732 is a big number. How many threads have you got?

[vmf229]

>
> LWPs aren’t scoped by process. The number is largely irrelevant, unless you
also know what else has been running on the system and how long it’s been
>booted.
 

Hmmmm, do not have linux, work with solaris mostly and lwps there are pretty
much scoped by process.
Run ps -A to figure out the process id, then look under /proc/<process_id>/lwp.

Anyway, it's been correctly pointed out that some *this* pointers do not look
right.

Looking at the call stack cannot see any sign of the strand being used to wrap
the handlers.
Even with the multithreaded server it should not be a problem most of the time,
i.e. as long as there are no simultaneous sends and receives on the same socket.

However imagine the client disconnects (and causing a call to the read handler)
right when the server sends the response back.
Without the strand, it could potentially cause some trouble.

[Slav]

Yeah, there is no strand in that stack, but that's the main asio's process,
rooted right from the io_service.run(). I am not sure, but think that all
strands are queued to that thread.

Sorry, I don't like when one programmers examine someone other's code, but
you already paid me so much of attention :), I attached files to the
message. Public functions there are called at any time from different
threads.
Thank you.


2012/8/16 vmf229 <***@hotmail.com>

> >
> > LWPs aren’t scoped by process. The number is largely irrelevant, unless
> you
> also know what else has been running on the system and how long it’s been
> >booted.
>
>
> Hmmmm, do not have linux, work with solaris mostly and lwps there are
> pretty
> much scoped by process.
> Run ps -A to figure out the process id, then look under
> /proc/<process_id>/lwp.
>
> Anyway, it's been correctly pointed out that some *this* pointers do not
> look
> right.
>
> Looking at the call stack cannot see any sign of the strand being used to
> wrap
> the handlers.
> Even with the multithreaded server it should not be a problem most of the
> time,
> i.e. as long as there are no simultaneous sends and receives on the same
> socket.
>
> However imagine the client disconnects (and causing a call to the read
> handler)
> right when the server sends the response back.
> Without the strand, it could potentially cause some trouble.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>

[Christof Meerwald]

On Thu, 16 Aug 2012 16:12:40 +0400, Slav wrote:
> Sorry, I don't like when one programmers examine someone other's code, but
> you already paid me so much of attention :), I attached files to the
> message. Public functions there are called at any time from different
> threads.

My guess is that you are doing an async_write on a socket, but while
waiting for that to complete you get an error from an async_read on
the same socket and "Drop" (and delete) that client (including the
socket). When the async_write then completes, the socket has already
been deleted.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[Marat Abrarov]

May be handler tracking (http://www.boost.org/doc/libs/1_50_0/doc/html/boost_asio/overview/core/handler_tracking.html)
can help the topic starter?

Regards,
Marat Abrarov.

[vmf229]

Christof Meerwald <***@...> writes:

>
> My guess is that you are doing an async_write on a socket, but while
> waiting for that to complete you get an error from an async_read on
> the same socket and "Drop" (and delete) that client (including the
> socket). When the async_write then completes, the socket has already
> been deleted.
>
> Christof
>

I would agree with that analysis.
Also, in my experience, with things like asio it may be rather tricky to
manage the object lifetime using straight pointers.
Even if you manage to get it right, it is still going to be flaky as any
subsequent change would stand a good chance of breaking it.
So in practical terms you might want to typedef a shared pointer as

class Client
{
...
typedef std::shared_ptr<Client> ptr_t;
};

and then replace every instance (including in std containers) of Client*
with Client::ptr_t.
In this case you would not have to worry when to delete Client*, it will
be deleted automatically in a thread-safe manner.
I see you use your own mutex for synchronization. There is nothing wrong
with that. However, with the library providing the strand mechanism, why
not to use it? Your code might look simpler and cleaner, besides there
is a chance the asio may handle handler (and thread) scheduling
somewhat better.

[Slav]

> My guess is that you are doing an async_write on a socket, but while
> waiting for that to complete you get an error from an async_read on
> the same socket and "Drop" (and delete) that client (including the
> socket). When the async_write then completes, the socket has already
> been deleted.

Well, I was sure (and even asked in this mailing-list) that only one of
"handle_write with error" or "handle_read with error" handler will be
called. By the way, that code was got almost without modifications from
asio's sample.
If both handlers will be called, then there is really an error. Thank you,
I'll fix it and see if it seg-faults vanished.

[Gruenke, Matt]

This post might be inappropriate. Click to display it.

[Gruenke, Matt]

This post might be inappropriate. Click to display it.

[Slav]

[w***@kleunen.nl]

Right, you can use the make_shared to avoid an extra memory allocation:

http://www.boost.org/doc/libs/1_50_0/libs/smart_ptr/make_shared.html


> If to be honest, I tried to avoid shared_ptrs for it's overheading memory
> allocations. Then less memory allocations happen for each
> message/connection to server, then faster server will work. And usage of
> shared_ptrs doubles memory allocations amount, am I right?
> Anyway, I implemented advised changes and run server, will see if he will
> fall...
>
> 2012/8/17 Gruenke, Matt <***@tycoint.com>
>
>> **
>> I should add that my comments should be taken in the abstract. I
>> haven't reviewed the code to determine whether the proposed solution
>> would
>> be problematic.
>>
>> Also, in conjunction with Boost.Asio, I also make frequent use
>> shared_ptr<> (and weak_ptr<>). It's certainly a very powerful and
>> useful
>> technique. I just think one must take the time to understand one's
>> state
>> machines and think about object lifetimes, or else memory leaks are
>> likely
>> to result (if you use shared_ptr<>; or stale pointers, if you don't).
>>
>>
>> Matt
>>
>>
>> ------------------------------
>> *From:* Gruenke, Matt [mailto:***@Tycoint.com]
>> *Sent:* Fri 8/17/2012 3:04 AM
>>
>> *To:* asio-***@lists.sourceforge.net
>> *Subject:* Re: [asio-users] Segmentation fault.
>>
>> > Even if you manage to get it right, it is still going to be flaky as
>> any
>> > subsequent change would stand a good chance of breaking it.
>> No. There should be no mystery about when you've got operations
>> pending.
>> This is part of the library interface and really *shouldn't* change.
>>
>>
>> > and then replace every instance (including in std containers) of
>> Client*
>> > with Client::ptr_t.
>> Repeat after me: shared pointers != garbage collection.
>>
>> Throwing shared pointers around with abandon will create memory leaks
>> that
>> are difficult to track down and resolve. You need to *think *about
>> object ownership and lifetime. There's no way around that. If you
>> don't
>> want to deal with it, then consider using a language with proper garbage
>> collection, like Java or C#.
>>
>> I hope this doesn't seem harsh, but I think it's important that people
>> not
>> regard shared_ptr<> as some magic bullet. It's a very powerful tool,
>> but
>> it has real and serious limitations that its users should know well.
>>
>>
>> Matt
>>
>>
>> ------------------------------
>> *From:* vmf229 [mailto:***@hotmail.com]
>> *Sent:* Thu 8/16/2012 8:19 PM
>> *To:* asio-***@lists.sourceforge.net
>> *Subject:* Re: [asio-users] Segmentation fault.
>>
>> Christof Meerwald <***@...> writes:
>>
>> >
>> > My guess is that you are doing an async_write on a socket, but while
>> > waiting for that to complete you get an error from an async_read on
>> > the same socket and "Drop" (and delete) that client (including the
>> > socket). When the async_write then completes, the socket has already
>> > been deleted.
>> >
>> > Christof
>> >
>>
>> I would agree with that analysis.
>> Also, in my experience, with things like asio it may be rather tricky to
>> manage the object lifetime using straight pointers.
>> Even if you manage to get it right, it is still going to be flaky as any
>> subsequent change would stand a good chance of breaking it.
>> So in practical terms you might want to typedef a shared pointer as
>>
>> class Client
>> {
>> ...
>> typedef std::shared_ptr<Client> ptr_t;
>> };
>>
>> and then replace every instance (including in std containers) of Client*
>> with Client::ptr_t.
>> In this case you would not have to worry when to delete Client*, it will
>> be deleted automatically in a thread-safe manner.
>> I see you use your own mutex for synchronization. There is nothing wrong
>> with that. However, with the library providing the strand mechanism, why
>> not to use it? Your code might look simpler and cleaner, besides there
>> is a chance the asio may handle handler (and thread) scheduling
>> somewhat better.
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> asio-users mailing list
>> asio-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/asio-users
>> _______________________________________________
>> Using Asio? List your project at
>> http://think-async.com/Asio/WhoIsUsingAsio
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> asio-users mailing list
>> asio-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/asio-users
>> _______________________________________________
>> Using Asio? List your project at
>> http://think-async.com/Asio/WhoIsUsingAsio
>>
>>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>

[w***@kleunen.nl]

You can always use an intrusive ptr, this avoids the extra allocation. I
though the boost shared_ptr also has an intrusive "mode", but I can not
find the documentation, maybe I am wrong about this.

http://www.boost.org/doc/libs/1_50_0/libs/smart_ptr/intrusive_ptr.html



> If to be honest, I tried to avoid shared_ptrs for it's overheading memory
> allocations. Then less memory allocations happen for each
> message/connection to server, then faster server will work. And usage of
> shared_ptrs doubles memory allocations amount, am I right?
> Anyway, I implemented advised changes and run server, will see if he will
> fall...
>
> 2012/8/17 Gruenke, Matt <***@tycoint.com>
>
>> **
>> I should add that my comments should be taken in the abstract. I
>> haven't reviewed the code to determine whether the proposed solution
>> would
>> be problematic.
>>
>> Also, in conjunction with Boost.Asio, I also make frequent use
>> shared_ptr<> (and weak_ptr<>). It's certainly a very powerful and
>> useful
>> technique. I just think one must take the time to understand one's
>> state
>> machines and think about object lifetimes, or else memory leaks are
>> likely
>> to result (if you use shared_ptr<>; or stale pointers, if you don't).
>>
>>
>> Matt
>>
>>
>> ------------------------------
>> *From:* Gruenke, Matt [mailto:***@Tycoint.com]
>> *Sent:* Fri 8/17/2012 3:04 AM
>>
>> *To:* asio-***@lists.sourceforge.net
>> *Subject:* Re: [asio-users] Segmentation fault.
>>
>> > Even if you manage to get it right, it is still going to be flaky as
>> any
>> > subsequent change would stand a good chance of breaking it.
>> No. There should be no mystery about when you've got operations
>> pending.
>> This is part of the library interface and really *shouldn't* change.
>>
>>
>> > and then replace every instance (including in std containers) of
>> Client*
>> > with Client::ptr_t.
>> Repeat after me: shared pointers != garbage collection.
>>
>> Throwing shared pointers around with abandon will create memory leaks
>> that
>> are difficult to track down and resolve. You need to *think *about
>> object ownership and lifetime. There's no way around that. If you
>> don't
>> want to deal with it, then consider using a language with proper garbage
>> collection, like Java or C#.
>>
>> I hope this doesn't seem harsh, but I think it's important that people
>> not
>> regard shared_ptr<> as some magic bullet. It's a very powerful tool,
>> but
>> it has real and serious limitations that its users should know well.
>>
>>
>> Matt
>>
>>
>> ------------------------------
>> *From:* vmf229 [mailto:***@hotmail.com]
>> *Sent:* Thu 8/16/2012 8:19 PM
>> *To:* asio-***@lists.sourceforge.net
>> *Subject:* Re: [asio-users] Segmentation fault.
>>
>> Christof Meerwald <***@...> writes:
>>
>> >
>> > My guess is that you are doing an async_write on a socket, but while
>> > waiting for that to complete you get an error from an async_read on
>> > the same socket and "Drop" (and delete) that client (including the
>> > socket). When the async_write then completes, the socket has already
>> > been deleted.
>> >
>> > Christof
>> >
>>
>> I would agree with that analysis.
>> Also, in my experience, with things like asio it may be rather tricky to
>> manage the object lifetime using straight pointers.
>> Even if you manage to get it right, it is still going to be flaky as any
>> subsequent change would stand a good chance of breaking it.
>> So in practical terms you might want to typedef a shared pointer as
>>
>> class Client
>> {
>> ...
>> typedef std::shared_ptr<Client> ptr_t;
>> };
>>
>> and then replace every instance (including in std containers) of Client*
>> with Client::ptr_t.
>> In this case you would not have to worry when to delete Client*, it will
>> be deleted automatically in a thread-safe manner.
>> I see you use your own mutex for synchronization. There is nothing wrong
>> with that. However, with the library providing the strand mechanism, why
>> not to use it? Your code might look simpler and cleaner, besides there
>> is a chance the asio may handle handler (and thread) scheduling
>> somewhat better.
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> asio-users mailing list
>> asio-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/asio-users
>> _______________________________________________
>> Using Asio? List your project at
>> http://think-async.com/Asio/WhoIsUsingAsio
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> asio-users mailing list
>> asio-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/asio-users
>> _______________________________________________
>> Using Asio? List your project at
>> http://think-async.com/Asio/WhoIsUsingAsio
>>
>>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>

[Dale Wilson]

Quoting Slav <***@gmail.com>:

> If to be honest, I tried to avoid shared_ptrs for it's overheading memory
> allocations. Then less memory allocations happen for each
> message/connection to server, then faster server will work. And usage of
> shared_ptrs doubles memory allocations amount, am I right?

There will be an extra malloc at the time you create a new heap allocated object
and assign it to a shared pointer. After that, no, there are no extra mallocs
when you copy, assign or dereference the shared pointer. If you are creating
enough heap-allocated objects that this would be a problem then it's likely
that you already have a problem and should consider object pools or something
similar.

If you pass shared pointers by reference rather than value whenever possible I
think you find any performance difference is unmeasurable (Remember that you
have to include your code that tracks object lifetime in the comparison. It
can go away.)

And if, after all that profiling the code (speculating about performance is a
fool's game (one I'm playing right now, by the way.)) shows the extra malloc is
a problem, then as someone else mentioned, switch to intrusive pointers. It
takes a little extra coding on your part, but still less than managing object
lifetimes by-hand and most of the logic is already debugged for you.

Dale



> Anyway, I implemented advised changes and run server, will see if he will
> fall...
>
> 2012/8/17 Gruenke, Matt <***@tycoint.com>
>
> > **
> > I should add that my comments should be taken in the abstract. I
> > haven't reviewed the code to determine whether the proposed solution would
> > be problematic.
> >
> > Also, in conjunction with Boost.Asio, I also make frequent use
> > shared_ptr<> (and weak_ptr<>). It's certainly a very powerful and useful
> > technique. I just think one must take the time to understand one's state
> > machines and think about object lifetimes, or else memory leaks are likely
> > to result (if you use shared_ptr<>; or stale pointers, if you don't).
> >
> >
> > Matt
> >
> >
> > ------------------------------
> > *From:* Gruenke, Matt [mailto:***@Tycoint.com]
> > *Sent:* Fri 8/17/2012 3:04 AM
> >
> > *To:* asio-***@lists.sourceforge.net
> > *Subject:* Re: [asio-users] Segmentation fault.
> >
> > > Even if you manage to get it right, it is still going to be flaky as
> > any
> > > subsequent change would stand a good chance of breaking it.
> > No. There should be no mystery about when you've got operations pending.
> > This is part of the library interface and really *shouldn't* change.
> >
> >
> > > and then replace every instance (including in std containers) of Client*
> > > with Client::ptr_t.
> > Repeat after me: shared pointers != garbage collection.
> >
> > Throwing shared pointers around with abandon will create memory leaks that
> > are difficult to track down and resolve. You need to *think *about
> > object ownership and lifetime. There's no way around that. If you don't
> > want to deal with it, then consider using a language with proper garbage
> > collection, like Java or C#.
> >
> > I hope this doesn't seem harsh, but I think it's important that people not
> > regard shared_ptr<> as some magic bullet. It's a very powerful tool, but
> > it has real and serious limitations that its users should know well.
> >
> >
> > Matt
> >
> >
> > ------------------------------
> > *From:* vmf229 [mailto:***@hotmail.com]
> > *Sent:* Thu 8/16/2012 8:19 PM
> > *To:* asio-***@lists.sourceforge.net
> > *Subject:* Re: [asio-users] Segmentation fault.
> >
> > Christof Meerwald <***@...> writes:
> >
> > >
> > > My guess is that you are doing an async_write on a socket, but while
> > > waiting for that to complete you get an error from an async_read on
> > > the same socket and "Drop" (and delete) that client (including the
> > > socket). When the async_write then completes, the socket has already
> > > been deleted.
> > >
> > > Christof
> > >
> >
> > I would agree with that analysis.
> > Also, in my experience, with things like asio it may be rather tricky to
> > manage the object lifetime using straight pointers.
> > Even if you manage to get it right, it is still going to be flaky as any
> > subsequent change would stand a good chance of breaking it.
> > So in practical terms you might want to typedef a shared pointer as
> >
> > class Client
> > {
> > ...
> > typedef std::shared_ptr<Client> ptr_t;
> > };
> >
> > and then replace every instance (including in std containers) of Client*
> > with Client::ptr_t.
> > In this case you would not have to worry when to delete Client*, it will
> > be deleted automatically in a thread-safe manner.
> > I see you use your own mutex for synchronization. There is nothing wrong
> > with that. However, with the library providing the strand mechanism, why
> > not to use it? Your code might look simpler and cleaner, besides there
> > is a chance the asio may handle handler (and thread) scheduling
> > somewhat better.
> >
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > asio-users mailing list
> > asio-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/asio-users
> > _______________________________________________
> > Using Asio? List your project at
> > http://think-async.com/Asio/WhoIsUsingAsio
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > asio-users mailing list
> > asio-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/asio-users
> > _______________________________________________
> > Using Asio? List your project at
> > http://think-async.com/Asio/WhoIsUsingAsio
> >
> >
>

[Marat Abrarov]

Hi, Slav.

Sorry, if I'm spamming you but I see comments in Russian in the source code you have attached (I'm still exploring
them).

> If to be honest, I tried to avoid shared_ptrs for it's overheading memory allocations.

See http://asio-samples.blogspot.com/2012/07/asio-performance-test.html. At Windows it seems that I have no any
noticeable overhead related to reference counting. Also boost::make_shared helps to avoid double memory allocation (for
object itself and for reference counters of boost::shared_ptr).

Regards,
Marat Abrarov.

[Slav]

> There will be an extra malloc at the time you create a new heap allocated
object
> and assign it to a shared pointer. After that, no, there are no extra
mallocs
> when you copy, assign or dereference the shared pointer.
Well, when you don't use shared_ptrs there are no memory allocations when
you pass pointers around too. So, it does doubles amount of memory
allocations - each time when you need to allocate an object, you have to
allocate another part of memory for technical usage. I cannot give a link
now, but I try to always remember good thing said: average program at 95%
of it's time is occupied within malloc() function.

> See http://asio-samples.blogspot.com/2012/07/asio-performance-test.html
Oh, it's so much of work done in that field... Thanks!

P.S. I attached newly rewritten code (to the usage of shared_ptrs) on which
server is currently running if someone interested. All russians comments
rewritten to english :). Server is still working without falls... (but it's
a little early to say something).

[Gruenke, Matt]

From: Slav
Sent: Sat 8/18/2012 3:17 AM
Subject: Re: [asio-users] Segmentation fault.

> I try to always remember good thing said: average program at 95% of it's time is occupied within malloc() function.

If you're concerned about that, use a profiler. I've never seen anything remotely that extreme, though I don't doubt it can happen.

Also, not all malloc's are equal. I've written tiny benchmarks and run them over the years, and I've consistently found smaller mallocs+frees to be much cheaper than bigger ones.

In this case, you know the malloc will be small, since shared ptr just needs enough space for the refcount. But let's take your pessimistic assumption that you'll double your dynamic memory allocation overhead if you switch to shared_ptr's. You could predict that upper bound by profiling your program, looking at all the time spent in malloc-related calls, and doubling it. But maybe that number is still acceptable. Until you start profiling, you're just flying blind.


Matt

[Slav]

Well, more than two weeks past after I applied shown modifications within
servers and all 3 of them are still working, each one processed ~10
millions clients and no memory leaks seemed to be occured.
Well done, Asio and to you, guys! You helped me very much! This library
works perfectly for me now.
Anyway, I think that snippets of such code must be within library's
tutorials as to minimally show how to make a class which handles incoming
connections/disconnections, provides a way to send data to clients at any
time within multithreaded application and drop that client at any time too.

2012/8/19 Gruenke, Matt <***@tycoint.com>

> **
> *From:* Slav
> *Sent:* Sat 8/18/2012 3:17 AM
>
> *Subject:* Re: [asio-users] Segmentation fault.
>
> > I try to always remember good thing said: average program at 95% of
> it's time is occupied within malloc() function.
>
> If you're concerned about that, use a profiler. I've never seen anything
> remotely that extreme, though I don't doubt it can happen.
>
> Also, not all malloc's are equal. I've written tiny benchmarks and run
> them over the years, and I've consistently found smaller mallocs+frees to
> be much cheaper than bigger ones.
>
> In this case, you know the malloc will be small, since shared ptr just
> needs enough space for the refcount. But let's take your pessimistic
> assumption that you'll double your dynamic memory allocation overhead if
> you switch to shared_ptr's. You could predict that upper bound by
> profiling your program, looking at all the time spent in malloc-related
> calls, and doubling it. But maybe that number is still acceptable. Until
> you start profiling, you're just flying blind.
>
>
> Matt
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
>

[Gruenke, Matt]

I'm glad you got your troubles sorted out.



I'd just note that one problem I've encountered with some of the more
involved examples is a lack of explanation (or if there is, I missed
it). Once an example reaches thousands of lines or multiple files, it
becomes much more intimidating and it's much more difficult to pick out
the important bits that are unique to that example. I guess someone
really needs to write a book on Asio.

;)



There is a wiki, however. I suppose we could try to make and document
some more substantial examples as a community effort.



http://think-async.com/Asio





One thing I'd like to see is coverage of more advanced design topics
involving Asio. For instance, techniques to manage the complexity of
state machines. I normally try to abstract and encapsulate subgraphs.
Something else we might like to cover is debugging techniques. Also,
there's a FAQ we might try to fill out, but perhaps it'd be worth having
a separate trouble-shooting guide.





Matt





From: Slav
Sent: Monday, August 27, 2012 8:24 AM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Segmentation fault.



Well, more than two weeks past after I applied shown modifications
within servers and all 3 of them are still working, each one processed
~10 millions clients and no memory leaks seemed to be occured.
Well done, Asio and to you, guys! You helped me very much! This library
works perfectly for me now.
Anyway, I think that snippets of such code must be within library's
tutorials as to minimally show how to make a class which handles
incoming connections/disconnections, provides a way to send data to
clients at any time within multithreaded application and drop that
client at any time too.

2012/8/19 Gruenke, Matt

From: Slav
Sent: Sat 8/18/2012 3:17 AM


Subject: Re: [asio-users] Segmentation fault.



> I try to always remember good thing said: average program at 95% of
it's time is occupied within malloc() function.

If you're concerned about that, use a profiler. I've never seen
anything remotely that extreme, though I don't doubt it can happen.



Also, not all malloc's are equal. I've written tiny benchmarks and run
them over the years, and I've consistently found smaller mallocs+frees
to be much cheaper than bigger ones.



In this case, you know the malloc will be small, since shared ptr just
needs enough space for the refcount. But let's take your pessimistic
assumption that you'll double your dynamic memory allocation overhead if
you switch to shared_ptr's. You could predict that upper bound by
profiling your program, looking at all the time spent in malloc-related
calls, and doubling it. But maybe that number is still acceptable.
Until you start profiling, you're just flying blind.





Matt

[Green, Cliff]

>> I guess someone really needs to write a book on Asio.

Definitely! I think Chris has done an excellent job for open source, completely uncompensated (or at least not compensated directly). But there's undoubtedly room for a book (and I've had an outline at the back of my mind for a couple of years, unfortunately I may never have the time).

With the expertise on this list someone (or a group?) could put together a book that would be the modern C++ equivalent of Stevens Unix Network Programming.

Cliff

[Christof Meerwald]

On Mon, 27 Aug 2012 12:08:19 -0700, Green, Cliff wrote:
>>> I guess someone really needs to write a book on Asio.
[...]
> With the expertise on this list someone (or a group?) could put together a =
> book that would be the modern C++ equivalent of Stevens Unix Network Progra=
> mming.

Keep in mind that the C++ Standards Committee is looking at adding
networking support to the standard library - so that might affect the
direction things will moving to.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[Green, Cliff]

It's based on Chris' Asio proposal, correct? (I'm pretty sure he wrote the proposal, based on Asio.)

Of course what gets standardized will be different, but (I assume) not architecturally, more in the specifics (e.g. buffers might be different or not included, headers / contents different, etc). Similar to Stepanov / Lee's STL inclusion in the first standard - the set of headers was substantially streamlined and changed, but the architecture remained essentially what was proposed.

It might be worthwhile asking Chris if he's working on a book (a while back he was offering courses, and I assume there were course notes included) ...

Cliff


-----Original Message-----
From: Christof Meerwald [mailto:***@cmeerw.org]
Sent: Monday, August 27, 2012 12:42 PM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Segmentation fault.

On Mon, 27 Aug 2012 12:08:19 -0700, Green, Cliff wrote:
>>> I guess someone really needs to write a book on Asio.
[...]
> With the expertise on this list someone (or a group?) could put
> together a = book that would be the modern C++ equivalent of Stevens
> Unix Network Progra= mming.

Keep in mind that the C++ Standards Committee is looking at adding networking support to the standard library - so that might affect the direction things will moving to.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

[Christof Meerwald]

On Mon, 27 Aug 2012 15:40:26 -0700, Green, Cliff wrote:
> It's based on Chris' Asio proposal, correct? (I'm pretty sure he
> wrote the proposal, based on Asio.)

It's not a simple as that - asio is one of the proposals, but there
are other proposals (POCO) as well.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[Gruenke, Matt]

Well, if you want to make it a collaborative effort, perhaps setting up
a dedicated mailing list and wiki would be a good place to start. The
wiki might at least be a good way to start sketching the outline, if not
the final product.



If you want to make a book in the more traditional format, I'd setup a
source repository and start writing XML Docbook. Docbook is used by
LDP, and can easily be retargeted to print and web (and I assume various
eReaders).





Matt





From: Green, Cliff
Sent: Monday, August 27, 2012 3:08 PM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Segmentation fault.



>> I guess someone really needs to write a book on Asio.



Definitely! I think Chris has done an excellent job for open source,
completely uncompensated (or at least not compensated directly). But
there's undoubtedly room for a book (and I've had an outline at the back
of my mind for a couple of years, unfortunately I may never have the
time).



With the expertise on this list someone (or a group?) could put together
a book that would be the modern C++ equivalent of Stevens Unix Network
Programming.



Cliff

[Gruenke, Matt]

While ASIO is much more streamlined than the sockets API, it introduces
its own complexities. Or, to put it another way, it facilitates a more
advanced programming model. Don't underestimate the coverage needed to
explain that programming model and how it's supported by ASIO.



Therefore, I see two separate topics. The first is the ASIO programming
model & techniques, tips, and tricks. The second is network programming
with ASIO, largely building on the first, but focused on the subject of
network programming with ASIO serving more of a supporting role. A
possible follow-on might cover how to do other sorts of things with
ASIO.



Regarding the first, although I haven't gone back to read the latest
version of Chris' excellent tutorial, I feel there are some areas that
aren't sufficiently covered (most of which I've mentioned earlier in the
thread). That said, it was still enough to get us (and many others)
started.





Matt







From: Wouter van Kleunen
Sent: Wednesday, August 29, 2012 1:21 PM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Segmentation fault.




If I look at the index of Unix Network Programming, mentioned by Cliff,
it covers alot of unix API details. With asio you will have alot less
overhead of covering apis. Would definitly be interesting to write
something like that.

Wouter

[Wouter van Kleunen]

Op 1-9-2012 23:57, Gruenke, Matt schreef:
>
> While ASIO is much more streamlined than the sockets API, it
> introduces its own complexities. Or, to put it another way, it
> facilitates a more advanced programming model. Don't underestimate
> the coverage needed to explain that programming model and how it's
> supported by ASIO.
>
> Therefore, I see two separate topics. The first is the ASIO
> programming model & techniques, tips, and tricks. The second is
> network programming with ASIO, largely building on the first, but
> focused on the subject of network programming with ASIO serving more
> of a supporting role. A possible follow-on might cover how to do
> other sorts of things with ASIO.
>
> Regarding the first, although I haven't gone back to read the latest
> version of Chris' excellent tutorial, I feel there are some areas that
> aren't sufficiently covered (most of which I've mentioned earlier in
> the thread). That said, it was still enough to get us (and many
> others) started.
>

Well, I think to read Chris his excellent tutorial you need some basic
knowledge of networking. I think "Unix Network Programming" covers these
basics and then goes into details of how to program them on a unix system.

I agree you first need to cover the asio programming model and then
cover how to use it to do network programming. However I think before
you start covering asio you would first need to introduce ipv4/ipv6,
hostnames and network addressing, tcp and udp.

Ok, I guess you are right, there is also an overhead in covering the
api, just different overhead.

Wouter
>
> Matt
>
> *From:*Wouter van Kleunen
> *Sent:* Wednesday, August 29, 2012 1:21 PM
> *To:* asio-***@lists.sourceforge.net
> <mailto:asio-***@lists.sourceforge.net>
> *Subject:* Re: [asio-users] Segmentation fault.
>
>
> If I look at the index of Unix Network Programming, mentioned by
> Cliff, it covers alot of unix API details. With asio you will have
> alot less overhead of covering apis. Would definitly be interesting to
> write something like that.
>
> Wouter
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio

[Wouter van Kleunen]

If I look at the index of Unix Network Programming, mentioned by Cliff,
it covers alot of unix API details. With asio you will have alot less
overhead of covering apis. Would definitly be interesting to write
something like that.

Wouter


Op 27-8-2012 21:22, Gruenke, Matt schreef:
>
> Well, if you want to make it a collaborative effort, perhaps setting
> up a dedicated mailing list and wiki would be a good place to start.
> The wiki might at least be a good way to start sketching the outline,
> if not the final product.
>
> If you want to make a book in the more traditional format, I'd setup a
> source repository and start writing XML Docbook. Docbook is used by
> LDP, and can easily be retargeted to print and web (and I assume
> various eReaders).
>
> Matt
>
> *From:*Green, Cliff
> *Sent:* Monday, August 27, 2012 3:08 PM
> *To:* asio-***@lists.sourceforge.net
> *Subject:* Re: [asio-users] Segmentation fault.
>
> >>I guess someone really needs to write a book on Asio.
>
> Definitely! I think Chris has done an excellent job for open source,
> completely uncompensated (or at least not compensated directly). But
> there's undoubtedly room for a book (and I've had an outline at the
> back of my mind for a couple of years, unfortunately I may never have
> the time).
>
> With the expertise on this list someone (or a group?) could put
> together a book that would be the modern C++ equivalent of Stevens
> Unix Network Programming.
>
> Cliff
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio

[Christof Meerwald]

On Mon, 27 Aug 2012 16:24:29 +0400, Slav wrote:
> Anyway, I think that snippets of such code must be within library's
> tutorials as to minimally show how to make a class which handles incoming
> connections/disconnections, provides a way to send data to clients at any
> time within multithreaded application and drop that client at any time too.

Actually, the chat_server example almost covers those things - see
http://www.boost.org/doc/libs/1_51_0/doc/html/boost_asio/example/chat/chat_server.cpp


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[Christof Meerwald]

On Wed, 15 Aug 2012 09:52:33 +0000 (UTC), vmf229 wrote:
>> [Switching to Thread 0x7ffecb7fe700 (LWP 23732)]
> 23732 is a big number. How many threads have you got?

But that's just a unique id - it doesn't provide any information about
the number of threads used by the application.


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

[unknown]

--047d7b2e4e3491a8a104c773def6
Content-Type: text/plain; charset=ISO-8859-1

If to be honest, I tried to avoid shared_ptrs for it's overheading memory
allocations. Then less memory allocations happen for each
message/connection to server, then faster server will work. And usage of
shared_ptrs doubles memory allocations amount, am I right?
Anyway, I implemented advised changes and run server, will see if he will
fall...

2012/8/17 Gruenke, Matt <***@tycoint.com>

> **
> I should add that my comments should be taken in the abstract. I
> haven't reviewed the code to determine whether the proposed solution would
> be problematic.
>
> Also, in conjunction with Boost.Asio, I also make frequent use
> shared_ptr<> (and weak_ptr<>). It's certainly a very powerful and useful
> technique. I just think one must take the time to understand one's state
> machines and think about object lifetimes, or else memory leaks are likely
> to result (if you use shared_ptr<>; or stale pointers, if you don't).
>
>
> Matt
>
>
> ------------------------------
> *From:* Gruenke, Matt [mailto:***@Tycoint.com]
> *Sent:* Fri 8/17/2012 3:04 AM
>
> *To:* asio-***@lists.sourceforge.net
> *Subject:* Re: [asio-users] Segmentation fault.
>
> > Even if you manage to get it right, it is still going to be flaky as
> any
> > subsequent change would stand a good chance of breaking it.
> No. There should be no mystery about when you've got operations pending.
> This is part of the library interface and really *shouldn't* change.
>
>
> > and then replace every instance (including in std containers) of Client*
> > with Client::ptr_t.
> Repeat after me: shared pointers != garbage collection.
>
> Throwing shared pointers around with abandon will create memory leaks that
> are difficult to track down and resolve. You need to *think *about
> object ownership and lifetime. There's no way around that. If you don't
> want to deal with it, then consider using a language with proper garbage
> collection, like Java or C#.
>
> I hope this doesn't seem harsh, but I think it's important that people not
> regard shared_ptr<> as some magic bullet. It's a very powerful tool, but
> it has real and serious limitations that its users should know well.
>
>
> Matt
>
>
> ------------------------------
> *From:* vmf229 [mailto:***@hotmail.com]
> *Sent:* Thu 8/16/2012 8:19 PM
> *To:* asio-***@lists.sourceforge.net
> *Subject:* Re: [asio-users] Segmentation fault.
>
> Christof Meerwald <***@...> writes:
>
> >
> > My guess is that you are doing an async_write on a socket, but while
> > waiting for that to complete you get an error from an async_read on
> > the same socket and "Drop" (and delete) that client (including the
> > socket). When the async_write then completes, the socket has already
> > been deleted.
> >
> > Christof
> >
>
> I would agree with that analysis.
> Also, in my experience, with things like asio it may be rather tricky to
> manage the object lifetime using straight pointers.
> Even if you manage to get it right, it is still going to be flaky as any
> subsequent change would stand a good chance of breaking it.
> So in practical terms you might want to typedef a shared pointer as
>
> class Client
> {
> ...
> typedef std::shared_ptr<Client> ptr_t;
> };
>
> and then replace every instance (including in std containers) of Client*
> with Client::ptr_t.
> In this case you would not have to worry when to delete Client*, it will
> be deleted automatically in a thread-safe manner.
> I see you use your own mutex for synchronization. There is nothing wrong
> with that. However, with the library providing the strand mechanism, why
> not to use it? Your code might look simpler and cleaner, besides there
> is a chance the asio may handle handler (and thread) scheduling
> somewhat better.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
>

--047d7b2e4e3491a8a104c773def6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If to be honest, I tried to avoid shared_ptrs for it&#39;s overheading memory allocations. Then less memory allocations happen for each message/connection to server, then faster server will work. And usage of shared_ptrs doubles memory allocations amount, am I right?<br>
Anyway, I implemented advised changes and run server, will see if he will fall...<br><br><div class="gmail_quote">2012/8/17 Gruenke, Matt <span dir="ltr">&lt;<a href="mailto:***@tycoint.com" target="_blank">***@tycoint.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>



<div>
<div dir="ltr">
<div dir="ltr"><font color="#000000" face="Arial">I should add that my comments
should be taken in the abstract.  I haven&#39;t reviewed the code to determine
whether the proposed solution would be problematic.</font></div>
<div dir="ltr"><font color="#000000" face="Arial"></font> </div>
<div dir="ltr"><font color="#000000" face="Arial">Also, in conjunction with
Boost.Asio, I also make frequent use shared_ptr&lt;&gt; (and
weak_ptr&lt;&gt;).  It&#39;s certainly a very powerful and useful
technique.  I just think one must take the time to understand one&#39;s state
machines and think about object lifetimes, or else memory leaks are likely to
result (if you use shared_ptr&lt;&gt;; or stale pointers, if you
don&#39;t).</font></div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial">Matt</font></div>
<div dir="ltr"><font face="Arial"></font> </div></div>
<div dir="ltr"><br>
<hr>
<font face="Tahoma"><b>From:</b> Gruenke, Matt
[mailto:<a href="mailto:***@Tycoint.com" target="_blank">***@Tycoint.com</a>]<br><b>Sent:</b> Fri 8/17/2012 3:04
AM<div><div class="h5"><br><b>To:</b> <a href="mailto:asio-***@lists.sourceforge.net" target="_blank">asio-***@lists.sourceforge.net</a><br><b>Subject:</b> Re:
[asio-users] Segmentation fault.<br></div></div></font><br></div><div><div class="h5">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><font color="#000000" face="Arial">&gt; Even if you manage to
get it right, it is still going to be flaky as any<br>&gt; subsequent change
would stand a good chance of breaking it.<br></font></div>
<div dir="ltr"><font color="#000000" face="Arial">No.  There should be no
mystery about when you&#39;ve got operations pending.  This is part of the
library interface and really <i>shouldn&#39;t</i> change.</font></div></div>
<div dir="ltr"> </div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial">&gt; </font><font face="Arial">and
then replace every instance (including in std containers) of Client*<br>&gt;
with Client::ptr_t.<br></font></div>
<div dir="ltr"><font face="Arial">Repeat after me: shared pointers != garbage
collection.</font></div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial">Throwing shared pointers around with
abandon will create memory leaks that are difficult to track down and
resolve.  You need to <i>think </i>about object ownership and
lifetime.  There&#39;s no way around that.  If you don&#39;t want to deal with
it, then consider using a language with proper garbage collection, like Java or
C#.</font></div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial">I hope this doesn&#39;t seem harsh, but I think
it&#39;s important that people not regard shared_ptr&lt;&gt; as some magic
bullet.  It&#39;s a very powerful tool, but it has real and serious limitations
that its users should know well.</font></div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial"></font> </div>
<div dir="ltr"><font face="Arial">Matt</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><br>
<hr>
<font face="Tahoma"><b>From:</b> vmf229
[mailto:<a href="mailto:***@hotmail.com" target="_blank">***@hotmail.com</a>]<br><b>Sent:</b> Thu 8/16/2012 8:19 PM<br><b>To:</b>
<a href="mailto:asio-***@lists.sourceforge.net" target="_blank">asio-***@lists.sourceforge.net</a><br><b>Subject:</b> Re: [asio-users]
Segmentation fault.<br></font><br></div>
<div>
<p><font>Christof Meerwald &lt;***@...&gt; writes:<br><br>&gt;<br>&gt;
My guess is that you are doing an async_write on a socket, but while<br>&gt;
waiting for that to complete you get an error from an async_read on<br>&gt; the
same socket and &quot;Drop&quot; (and delete) that client (including the<br>&gt; socket).
When the async_write then completes, the socket has already<br>&gt; been
deleted.<br>&gt;<br>&gt; Christof<br>&gt;<br><br>I would agree with that
analysis.<br>Also, in my experience, with things like asio it may be rather
tricky to<br>manage the object lifetime using straight pointers.<br>Even if you
manage to get it right, it is still going to be flaky as any<br>subsequent
change would stand a good chance of breaking it.<br>So in practical terms you
might want to typedef a shared pointer as<br><br>class
Client<br>{<br>    ...<br>    typedef
std::shared_ptr&lt;Client&gt; ptr_t;<br>};<br><br>and then replace every
instance (including in std containers) of Client*<br>with Client::ptr_t.<br>In
this case you would not have to worry when to delete Client*, it will<br>be
deleted automatically in a thread-safe manner.<br>I see you use your own mutex
for synchronization. There is nothing wrong<br>with that. However, with the
library providing the strand mechanism, why<br>not to use it? Your code might
look simpler and cleaner, besides there<br>is a chance the asio may handle
handler (and thread) scheduling<br>somewhat
better.<br><br><br><br><br><br>------------------------------------------------------------------------------<br>Live
Security Virtual Conference<br>Exclusive live event will cover all the ways
today&#39;s security and<br>threat landscape has changed and how IT managers can
respond. Discussions<br>will include endpoint security, mobile security and the
latest in malware<br>threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>_______________________________________________<br>
asio-users
mailing list<br><a href="mailto:asio-***@lists.sourceforge.net" target="_blank">asio-***@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/asio-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/asio-users</a><br>
_______________________________________________<br>Using
Asio? List your project at<br><a href="http://think-async.com/Asio/WhoIsUsingAsio" target="_blank">http://think-async.com/Asio/WhoIsUsingAsio</a><br></font></p></div></div></div></div></div>
<br>------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>_______________________________________________<br>
asio-users mailing list<br>
<a href="mailto:asio-***@lists.sourceforge.net">asio-***@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/asio-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/asio-users</a><br>
_______________________________________________<br>
Using Asio? List your project at<br>
<a href="http://think-async.com/Asio/WhoIsUsingAsio" target="_blank">http://think-async.com/Asio/WhoIsUsingAsio</a><br>
<br></blockquote></div><br>

--047d7b2e4e3491a8a104c773def6--