[zeromq-dev] Segfault in zmq_data_init or related

A. Mark gougolith at gmail.com
Fri Jan 11 18:32:27 CET 2013


I'm seeing the following core dump issue with large malloc() buffers
size>1MB when used with zmq_data_init:

Program terminated with signal 11, Segmentation fault.
#0  __memcpy_ssse3_back () at
98    ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or
(gdb) up
#1  0x0000000000426068 in zmq::encoder_base_t<zmq::v1_encoder_t>::get_data
(this=0x7f49d4000bd0, data_=0x7f49d4000dd8,
    size_=0x7f49d4000de0, offset_=0x0) at
52      return __builtin___memcpy_chk (__dest, __src, __len, __bos0
(gdb) up
#2  0x0000000000422c9e in zmq::stream_engine_t::out_event
(this=0x7f49d4000d90) at stream_engine.cpp:255
255            encoder->get_data (&outpos, &outsize);
(gdb) up
#3  0x0000000000419a2a in zmq::epoll_t::loop (this=0x7f49e0002fb0) at
158                    pe->events->out_event ();
(gdb) up
#4  0x00000000004243f6 in thread_routine (arg_=0x7f49e0003020) at
83            self->tfn (self->arg);
(gdb) up
#5  0x00007f49e7d03e9a in start_thread (arg=0x7f49e5f20700) at
308    pthread_create.c: No such file or directory.

The issue happens within this code segment:

    void *buf = NULL;
    zmq_msg_t msg;

    if( !(buf = malloc( message_size))){ perror("malloc"); return NULL;}

        for (i = 0; i != message_count; i++) {

            rc = zmq_msg_init_data (&msg, buf, message_size, NULL, NULL);
            if (rc != 0) {
                printf ("error in zmq_msg_init_data: %s\n", zmq_strerror
                return NULL;

            rc = zmq_msg_send( &msg, s, 0);
            if (rc < 0) {
                printf ("error in zmq_send: %s\n", zmq_strerror (errno));
            return NULL;
            rc = zmq_msg_close (&msg);
            if (rc != 0) {
                printf ("error in zmq_msg_close: %s\n", zmq_strerror
                exit (1);

The segfault occurs in the first iteration (i=0) with message_size=8MB,
with message_size < 1MB no issues. Itl looks like heap corruption, but I
investigated no further.
Unless this is a library issue I don't know if I'm doing anything illegal

Regards, Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130111/021f338b/attachment.htm>

More information about the zeromq-dev mailing list