Re: [boost] Is the async_read more reliable than async_read_some?

Subject: Re: [boost] Is the async_read more reliable than async_read_some?
From: hh h (jupiter.hce_at_[hidden])
Date: 2018-12-09 01:50:57

> How does it crash?  There's no fundamental reason
> why prepending your own header with the size
> wouldn't work.

I sent 4 bytes header and 221 bytes messages repeatedly (every 2
seconds) calling from async_write of a sender, the receiver works
correctly and perfectly at async_read for a couple minutes, then it
crashed in the statement of readMessageBody for 221 bytes message at
async_read(socket_, boost::asio::buffer(buffer, size), ....), where
the size = 221n I don't think it is related to my program, either some
bugs in async_read or libssl. Here is my debug:

Read body size = 221

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff69d4c01 in __GI___libc_free (mem=0x5555557f7770) at malloc.c:3123
3123    malloc.c: No such file or directory.

(gdb) backtrace
#0  0x00007ffff69d4c01 in __GI___libc_free (mem=0x5555557f7770)
    at malloc.c:3123
#1  0x00007ffff796a8fc in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#2  0x00007ffff796a139 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#3  0x00007ffff796f9aa in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#4  0x00007ffff79797d5 in SSL_read ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#5  0x00005555555665b1 in boost::asio::ssl::detail::engine::do_read (
    this=0x5555557d0fe0, data=0x5555557f7765, length=221)
    at /usr/include/boost/asio/ssl/detail/impl/engine.ipp:309

........

(gdb) print (char *)mem
$2 = 0x5555557f7770 "n\226"

Thanks Steven and Cliff.

On 12/9/18, Steven Watanabe via Boost <boost_at_[hidden]> wrote:
> AMDG
>
> On 12/08/2018 04:51 PM, hh h wrote:
>> "If it uses some kind of delimiter, then async_read_until will work"
>>
>> What kind of delimiter can I use to make async_read_until will work?
>>
>
> I have no idea.  If you don't know already then
> your protocol is probably not designed to work
> that way.  If you're designing your own protocol,
> then sending the size first is probably simpler
> to implement.
>
>> The server to call async_read_some will be connected by thousands
>> devices, can the async_read_some cope with thousands different
>> messages without causing problems?
>>
>> I've just tried to run async_write using boost streambuf to pack
>> packet header and msgpack data together in one message data, but the
>> async_read in server site could only work a couple of minutes than it
>> crashed even I fixed all sizes in header file. It seems I can only use
>> the async_read_some for a stable server implementation.
>>
>
> How does it crash?  There's no fundamental reason
> why prepending your own header with the size
> wouldn't work.  The only likely issue that I
> see with this setup is that async_read will receive
> the entire message and buffer it in memory before it
> signals completion, which might be a problem if
> the messages are large.
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>