[zeromq-dev] (no subject)

josh knox cz82mak at gmail.com
Fri Dec 4 20:55:23 CET 2015


Hi Peter,

Good observation on the memcpy size. That is certainly correct.

I'll test it with this change over the weekend and have a go at it with gdb.

Thanks,

Josh

On Fri, Dec 4, 2015 at 2:22 PM, Peter Krey <peterjkrey at gmail.com> wrote:

> Hi,
>
>
> try replacing
> memcpy(message.data(), &status, message.size());
> with
> memcpy(message.data(), &status, sizeof(myData));
>
> this is just a guess and im not sure if this will work.
>
>
> your best bet to pin down the error is run GDB on your application so you
> can see what line the code is crashing on.
>
>
> Best,
> Peter
>
>
>
> On Fri, Dec 4, 2015 at 9:21 AM, josh knox <cz82mak at gmail.com> wrote:
>
>> Hi Pieter,
>>
>> I'll double check my usage of the messages. I could certainly be mucking
>> something up.
>>
>> My usage is simply:
>> 1. create zmq message.
>> 2. copy data into message data.
>> 3. publish
>>
>> This works great for the several different types I send out, until it
>> crashes. :(
>>
>> Thanks,
>>
>> Josh
>>
>>
>>
>> On Fri, Dec 4, 2015 at 12:08 PM, Pieter Hintjens <ph at imatix.com> wrote:
>>
>>> Something wrong in how you're using the messages IMO, though I'm not
>>> familiar enough with the C++ binding to tell you the correct usage.
>>>
>>> On Fri, Dec 4, 2015 at 5:12 PM, josh knox <cz82mak at gmail.com> wrote:
>>> >
>>> > Hi,
>>> >
>>> >
>>> > I've been running into a segfault since adding a zmq publication
>>> socket to
>>> > my application.
>>> >
>>> >
>>> > It usually runs fine, happily publishing various data at a few Hz.
>>> Nothing
>>> > high stress.
>>> >
>>> >
>>> > There are 2 varieties of segfaults  that occur.
>>> >
>>> > One of the following messages is printed to stderr when the crash
>>> occurs.
>>> >
>>> > Assertion failed: refs_ >= 0 (src/msg.cpp:337)
>>> > Assertion failed: check () (src/msg.cpp:248)
>>> >
>>> >
>>> > Sometimes I get this backtrace:
>>> >
>>> >
>>> > [Switching to Thread 0x7fffe57c0700 (LWP 8781)]
>>> > 0x00007ffff4d84cc9 in __GI_raise (sig=sig at entry=6)
>>> >     at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> > 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
>>> directory.
>>> > (gdb) bt
>>> > #0  0x00007ffff4d84cc9 in __GI_raise (sig=sig at entry=6)
>>> >     at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> > #1  0x00007ffff4d880d8 in __GI_abort () at abort.c:89
>>> > #2  0x00007ffff4dc1394 in __libc_message (do_abort=do_abort at entry=1,
>>> >     fmt=fmt at entry=0x7ffff4ecfb28 "*** Error in `%s': %s: 0x%s ***\n")
>>> >     at ../sysdeps/posix/libc_fatal.c:175
>>> > #3  0x00007ffff4dcd66e in malloc_printerr (ptr=<optimized out>,
>>> >     str=0x7ffff4ecbc31 "free(): invalid size", action=1) at
>>> malloc.c:4996
>>> > #4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at
>>> > malloc.c:3840
>>> > #5  0x00007ffff46cba25 in zmq::msg_t::close (this=this at entry
>>> =0x7fffd8000920)
>>> >     at src/msg.cpp:159
>>> > #6  0x00007ffff46e8864 in zmq::stream_engine_t::~stream_engine_t (
>>> >     this=0x7fffd8000900, __in_chrg=<optimized out>) at
>>> > src/stream_engine.cpp:162
>>> > #7  0x00007ffff46e8d79 in zmq::stream_engine_t::~stream_engine_t (
>>> >     this=0x7fffd8000900, __in_chrg=<optimized out>) at
>>> > src/stream_engine.cpp:174
>>> > #8  0x00007ffff46e7385 in zmq::stream_engine_t::error (
>>> >     this=this at entry=0x7fffd8000900,
>>> >     reason=reason at entry=zmq::stream_engine_t::connection_error)
>>> >     at src/stream_engine.cpp:940
>>> > #9  0x00007ffff46e856b in zmq::stream_engine_t::in_event
>>> > (this=0x7fffd8000900)
>>> >     at src/stream_engine.cpp:300
>>> > #10 0x00007ffff46c4cfe in zmq::epoll_t::loop (this=0x79c980) at
>>> > src/epoll.cpp:168
>>> > #11 0x00007ffff46ef350 in thread_routine (arg_=0x79ca00) at
>>> > src/thread.cpp:96
>>> > #12 0x00007ffff759e182 in start_thread (arg=0x7fffe57c0700) at
>>> > pthread_create.c:312
>>> > #13 0x00007ffff4e4847d in clone () at
>>> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>>> > (gdb)
>>> >
>>> > This is another backtrace I get occasionally:
>>> >
>>> >
>>> > Program terminated with signal SIGSEGV, Segmentation fault.
>>> > #0  __memcpy_sse2_unaligned () at
>>> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
>>> > 33      ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such
>>> file or
>>> > directory.
>>> > (gdb) bt
>>> > #0  __memcpy_sse2_unaligned () at
>>> > ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
>>> > #1  0x00007f6ac2b26c10 in memcpy (__len=<optimized out>,
>>> __src=<optimized
>>> > out>, __dest=<optimized out>)
>>> >     at /usr/include/x86_64-linux-gnu/bits/string3.h:51
>>> > #2  zmq::encoder_base_t<zmq::v2_encoder_t>::encode
>>> (this=0x7f6a98008bc0,
>>> > data_=0x7f6ab5359108, size_=<optimized out>)
>>> >     at src/encoder.hpp:123
>>> > #3  0x00007f6ac2b1b89f in zmq::stream_engine_t::out_event
>>> > (this=0x7f6aa8000900) at src/stream_engine.cpp:365
>>> > #4  0x00007f6ac2b11563 in zmq::session_base_t::read_activated
>>> > (this=0x7f6aa8001050, pipe_=0x7f6a980089e0)
>>> >     at src/session_base.cpp:264
>>> > #5  0x00007f6ac2afad7c in zmq::io_thread_t::in_event (this=0x1738c20)
>>> at
>>> > src/io_thread.cpp:83
>>> > #6  0x00007f6ac2af9d3e in zmq::epoll_t::loop (this=0x1737a90) at
>>> > src/epoll.cpp:176
>>> > #7  0x00007f6ac2b24350 in thread_routine (arg_=0x1737b10) at
>>> > src/thread.cpp:96
>>> > #8  0x00007f6ac59df182 in start_thread (arg=0x7f6ab535a700) at
>>> > pthread_create.c:312
>>> > #9  0x00007f6ac328047d in clone () at
>>> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>>> > (gdb)
>>> >
>>> > My zmq usage is pretty simple. Here is the code I've added to my app:
>>> >
>>> > 1. Initialize zmq stuff:
>>> >
>>> > std::string statusPubAddress;
>>> >
>>> > std::string
>>> >
>>> > // create zmq socket
>>> >
>>> > zmqContext = new zmq::context_t(2);
>>> > // bind the data publication
>>> >
>>> > // connect the status publication socket
>>> > txDataPub = new zmq::socket_t(*zmqContext, ZMQ_PUB);
>>> > try {
>>> >     cerr << "\n Opening Publication on address: " << statusPubAddress;
>>> >     txDataPub->bind(statusPubAddress.c_str());
>>> > }
>>> > catch(zmq::error_t &err) {
>>> >
>>> >     std::cerr << err.what() << ": " << statusPubAddress.c_str();
>>> >
>>> >
>>> >     throw(err);
>>> > }
>>> >
>>> >
>>> >
>>> > 2. I publish stuff like this:
>>> >
>>> > MyData status = GetStatus();  // simple struct, no pointers
>>> >
>>> > try {
>>> >
>>> >     zmq::message_t message(sizeof(MyData));
>>> >     memcpy(message.data(), &status, message.size());
>>> >     txDataPub->send(message, ZMQ_NOBLOCK);
>>> >
>>> > }
>>> >
>>> > catch(zmq::error_t &err) {
>>> >      std::cerr << "\nERROR: " <<err.what();
>>> >  }
>>> >
>>> > If I disable my zmq code, the crash goes away.
>>> >
>>> >
>>> >
>>> > Any pointers as to what might be causing this? Let me know if more info
>>> > would be helpful.
>>> >
>>> >
>>> > Thanks for any help!
>>> >
>>> >
>>> > Josh
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20151204/9e8d2646/attachment.htm>


More information about the zeromq-dev mailing list