Closed wch closed 4 years ago
More details. This is with 021, 026, 027, and 033 from the shiny-examples repo.
websockets-base.cpp:50:28: runtime error: store to misaligned address 0x6020000288f2 for type 'uint64_t', which requires 8 byte alignment
0x6020000288f2: note: pointer points here
80 14 81 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 01 00 00 ff ff ff 04 01 00 00 00 59 00
^
#0 0x7f6d183edb22 in WebSocketProto::createFrameHeader(Opcode, bool, unsigned long, int, char*, unsigned long*) const /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/websockets-base.cpp:50
#1 0x7f6d18404c0d in WSHyBiParser::createFrameHeaderFooter(Opcode, bool, unsigned long, int, char*, unsigned long*, char*, unsigned long*) const /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/websockets.cpp:155
#2 0x7f6d18408f60 in WebSocketConnection::sendWSMessage(Opcode, char const*, unsigned long) /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/websockets.cpp:266
#3 0x7f6d182dbb78 in void boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>::call<boost::shared_ptr<WebSocketConnection>, Opcode, char const*, unsigned long>(boost::shared_ptr<WebSocketConnection>&, void const*, Opcode&, char const*&, unsigned long&) const /_test_cache/3.7.0/lib/BH/include/boost/bind/mem_fn_template.hpp:384
#4 0x7f6d182d9e91 in void boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>::operator()<boost::shared_ptr<WebSocketConnection> >(boost::shared_ptr<WebSocketConnection>&, Opcode, char const*, unsigned long) const /_test_cache/3.7.0/lib/BH/include/boost/bind/mem_fn_template.hpp:399
#5 0x7f6d182d66e4 in void boost::_bi::list4<boost::_bi::value<boost::shared_ptr<WebSocketConnection> >, boost::_bi::value<Opcode>, boost::_bi::value<char*>, boost::_bi::value<unsigned long> >::operator()<boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>&, boost::_bi::list0&, int) /_test_cache/3.7.0/lib/BH/include/boost/bind/bind.hpp:463
#6 0x7f6d182d36b9 in boost::_bi::bind_t<void, boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptr<WebSocketConnection> >, boost::_bi::value<Opcode>, boost::_bi::value<char*>, boost::_bi::value<unsigned long> > >::operator()() /_test_cache/3.7.0/lib/BH/include/boost/bind/bind.hpp:1294
#7 0x7f6d182cff3c in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf3<void, WebSocketConnection, Opcode, char const*, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptr<WebSocketConnection> >, boost::_bi::value<Opcode>, boost::_bi::value<char*>, boost::_bi::value<unsigned long> > >, void>::invoke(boost::detail::function::function_buffer&) /_test_cache/3.7.0/lib/BH/include/boostn/function_template.hpp:158
#8 0x7f6d18219aec in boost::function0<void>::operator()() const /_test_cache/3.7.0/lib/BH/include/boost/function/function_template.hpp:763
#9 0x7f6d1821f49a in CallbackQueue::flush() /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/callbackqueue.cpp:47
#10 0x7f6d1821ee37 in flush_callback_queue(uv_async_s*) /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/callbackqueue.cpp:12
#11 0x7f6d1841f86d in uv__async_io src/unix/async.c:118
#12 0x7f6d1844c9f9 in uv__io_poll src/unix/linux-core.c:379
#13 0x7f6d1842156b in uv_run src/unix/core.c:363
#14 0x7f6d182b0d66 in io_thread(void*) /tmp/Rtmpl9uRZW/R.INSTALL43b4376d2716/httpuv/src/httpuv.cpp:136
#15 0x7f6d242fb6da in start_thread /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463
#16 0x7f6d24a4088e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12188e)
It looks like the solution is to use memcpy
instead of assignment here:
https://github.com/rstudio/httpuv/blob/a178e4a3e73605f4494b23b8b3e6b11c0e9f7310/src/websockets-base.cpp#L50
When running Shiny apps with
RDsan
from the R-debug image, this error occasionally happens:This should be OK on x86, but we should fix it in the future.
https://blog.quarkslab.com/unaligned-accesses-in-cc-what-why-and-solutions-to-do-it-properly.html