Why a "stack smashing detected" once ZeroMQ C++ client runs against a python Server?
Question: I'm trying to learn how to use **`ZeroMQ`** lib to exchange data ( a simple
'hello' ) between a client and a server.

* * *

## python ``client`` \- python ``server`` implementation works

With success I have created a client and a server in python and I could
exchange data.

* * *

## `C++` ``client`` \- python ``server`` implementation not

The next step was to create a client in **`C++`** and a server in python. I've
done like this:

`C++` client, **`client_cpp.cpp`** :

    
    
       #include <zmq.hpp>
       #include <string>
       #include <iostream>
    
    
       int main ()
       {
          zmq::context_t context (1);
          zmq::socket_t socket (context, ZMQ_REQ);
          std::cout << "Connecting to hello world server…" << std::endl;
          socket.connect ("tcp://localhost:5555");
          std::string message = "hello";
          zmq::message_t request (message.size());
          memcpy (request.data (), (message.c_str()), (message.size()));
          socket.send (request);
    
          return 0;
       }
    

I've compiled it using `CMake` with the following **`CMakeLists.txt`** :

    
    
       cmake_minimum_required(VERSION 2.8)
       project(ZmqProject)
    
       # This will file libzmq.so file from /usr/local/lib
       FIND_FILE(ZMQLIB libzmq.so /usr/local/lib)
       IF(NOT ZMQLIB)
       MESSAGE(SEND_ERROR "Ah.. Cannot find library libzmq.so.")
       ENDIF(NOT ZMQLIB)
    
       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
       set(SOURCE_FILES client_cpp.cpp)
    
       add_executable(ZmqProject ${SOURCE_FILES})
       # The following line will link with libzmq.so
       TARGET_LINK_LIBRARIES( ZmqProject ${ZMQLIB})
    

Then, the `python` server, **`server_python.py`** , is the following:

    
    
       # -*- coding: utf-8 -*-
       import time
       import zmq
    
       context = zmq.Context()
       socket = context.socket(zmq.REP)
       socket.bind("tcp://*:5555")
       message = socket.recv()
       print("Received data: %s" % message)
    

Executing those programs, this kind of error accours in the client in `C++`:

    
    
       *** stack smashing detected ***: ./ZmqProject terminated
       Aborted (core dumped)
    

and I can not receive nothing in the `python` server.

~~**`Q1:`** Why, what is wrong?~~

* * *

**`EDIT 1`** \- running the client through `valgrind` this is the output,
maybe it can be usefull:

    
    
    valgrind --leak-check=full -v ./ZmqProject 
    ==12291== Memcheck, a memory error detector
    ==12291== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
    ==12291== Using Valgrind-3.10.1 and LibVEX; rerun with -h for    copyright     info
    ==12291== Command: ./ZmqProject
    ==12291== 
    --12291-- Valgrind options:
    --12291--    --leak-check=full
    --12291--    -v
    --12291-- Contents of /proc/version:
    --12291--   Linux version 3.19.0-59-generic (buildd@lgw01-39) (gcc    version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #66~14.04.1-Ubuntu SMP Fri May 13     17:27:10 UTC 2016
    --12291-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
    --12291-- Page sizes: currently 4096, max supported 4096
    --12291-- Valgrind library directory: /usr/lib/valgrind
    --12291-- Reading syms from /home/fds/Scrivania/ClientProgram/build     /ZmqProject
    --12291-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/ld-2.19.so ..
    --12291--   .. CRC mismatch (computed 46abf574 wanted 3ca2d3ca)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
    --12291--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
    --12291--   .. CRC mismatch (computed 4f1eed43 wanted a323a3ab)
    --12291--    object doesn't have a symbol table
    --12291--    object doesn't have a dynamic symbol table
    --12291-- Scheduler: using generic scheduler lock implementation.
    --12291-- Reading suppressions file: /usr/lib/valgrind/default.supp
    ==12291== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-    12291-by-fds-on-???
    ==12291== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-    12291-by-fds-on-???
    ==12291== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-    12291-by-fds-on-???
    ==12291== 
    ==12291== TO CONTROL THIS PROCESS USING vgdb (which you probably
    ==12291== don't want to do, unless you know exactly what you're doing,
    ==12291== or are doing some strange experiment):
    ==12291==   /usr/lib/valgrind/../../bin/vgdb --pid=12291 ...command...
    ==12291== 
    ==12291== TO DEBUG THIS PROCESS USING GDB: start GDB like this
    ==12291==   /path/to/gdb ./ZmqProject
    ==12291== and then give GDB the following command
    ==12291==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=12291
    ==12291== --pid is optional if only one valgrind process is running
    ==12291== 
    --12291-- REDIR: 0x4019c50 (ld-linux-x86-64.so.2:strlen) redirected to 0x380764b1 (???)
    --12291-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-    linux.so
    --12291--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
    --12291--   .. CRC mismatch (computed fc68135e wanted 45f5e986)
    --12291--    object doesn't have a symbol table
    --12291-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
    --12291--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
    --12291--   .. CRC mismatch (computed ae683f7e wanted 08c06df2)
    --12291--    object doesn't have a symbol table
    ==12291== WARNING: new redirection conflicts with existing -- ignoring it
    --12291--     old: 0x04019c50 (strlen              ) R-> (0000.0) 0x380764b1 ???
    --12291--     new: 0x04019c50 (strlen              ) R-> (2007.0) 0x04c2e1a0 strlen
    --12291-- REDIR: 0x4019a00 (ld-linux-x86-64.so.2:index) redirected to 0x4c2dd50 (index)
    --12291-- REDIR: 0x4019c20 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2f2f0 (strcmp)
    --12291-- REDIR: 0x401a970 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c31da0 (mempcpy)
    --12291-- Reading syms from /usr/local/lib/libzmq.so.4.2.0
    --12291-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
    --12291--   Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 ..
    --12291--   .. CRC mismatch (computed dc37bb90 wanted ea8c3b40)
    --12291--    object doesn't have a symbol table
    --12291-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
    --12291--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
    --12291--   .. CRC mismatch (computed 6116126e wanted 54e3f1f2)
    --12291--    object doesn't have a symbol table
    --12291-- Reading syms from /lib/x86_64-linux-gnu/libc-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/libc-2.19.so ..
    --12291--   .. CRC mismatch (computed ac9b5ddb wanted a10d05bf)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/libpthread-2.19.so ..
    --12291--   .. CRC mismatch (computed 88040ace wanted 71b58165)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- Reading syms from /lib/x86_64-linux-gnu/librt-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/librt-2.19.so ..
    --12291--   .. CRC mismatch (computed 9efd3dd5 wanted ae0f290f)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/librt-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- Reading syms from /lib/x86_64-linux-gnu/libm-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/libm-2.19.so ..
    --12291--   .. CRC mismatch (computed 08659659 wanted 7ce1b39a)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- REDIR: 0x5696c50 (libc.so.6:strcasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x5698f40 (libc.so.6:strncasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x5696420 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x56946b0 (libc.so.6:rindex) redirected to 0x4c2da30 (rindex)
    --12291-- REDIR: 0x56929b0 (libc.so.6:strlen) redirected to 0x4c2e0e0 (strlen)
    --12291-- REDIR: 0x5695e90 (libc.so.6:__GI_memcmp) redirected to 0x4c30b80 (__GI_memcmp)
    --12291-- REDIR: 0x5690f60 (libc.so.6:strcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x5749e00 (libc.so.6:__strcmp_ssse3) redirected to 0x4c2f1b0 (strcmp)
    --12291-- REDIR: 0x514ee20 (libstdc++.so.6:operator new(unsigned long, std::nothrow_t const&)) redirected to 0x4c2b340 (operator new(unsigned long, std::nothrow_t const&))
    --12291-- REDIR: 0x568c660 (libc.so.6:malloc) redirected to 0x4c2ab10 (malloc)
    --12291-- REDIR: 0x568d130 (libc.so.6:calloc) redirected to 0x4c2cbf0 (calloc)
    --12291-- REDIR: 0x514ed90 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2b070 (operator new(unsigned long))
    --12291-- REDIR: 0x5759c90 (libc.so.6:__memmove_ssse3_back) redirected to 0x4c2f450 (memcpy@GLIBC_2.2.5)
    --12291-- REDIR: 0x514d0f0 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2c250 (operator delete(void*))
    --12291-- REDIR: 0x569b620 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x56a1ec0 (libc.so.6:__memcpy_sse2_unaligned) redirected to 0x4c2f6b0 (memcpy@@GLIBC_2.14)
    --12291-- REDIR: 0x5695e50 (libc.so.6:bcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
    --12291-- REDIR: 0x5769c60 (libc.so.6:__memcmp_sse4_1) redirected to 0x4c30c00 (__memcmp_sse4_1)
    Connecting to hello world server…
    --12291-- REDIR: 0x5690d40 (libc.so.6:__GI_strchr) redirected to 0x4c2db90 (__GI_strchr)
    --12291-- REDIR: 0x5692e20 (libc.so.6:__GI_strncmp) redirected to 0x4c2e930 (__GI_strncmp)
    --12291-- REDIR: 0x5695300 (libc.so.6:__GI_strstr) redirected to 0x4c32030 (__strstr_sse2)
    --12291-- REDIR: 0x5695b00 (libc.so.6:memchr) redirected to 0x4c2f390 (memchr)
    --12291-- REDIR: 0x569b670 (libc.so.6:__GI_memcpy) redirected to 0x4c2fc90 (__GI_memcpy)
    --12291-- REDIR: 0x568cd00 (libc.so.6:free) redirected to 0x4c2bd80 (free)
    --12291-- REDIR: 0x569d9b0 (libc.so.6:strchrnul) redirected to 0x4c319b0 (strchrnul)
    --12291-- REDIR: 0x5748450 (libc.so.6:__strncasecmp_avx) redirected to 0x4c2eb60 (strncasecmp)
    --12291-- REDIR: 0x5690fa0 (libc.so.6:__GI_strcmp) redirected to 0x4c2f200 (__GI_strcmp)
    --12291-- REDIR: 0x5696ae0 (libc.so.6:__GI_stpcpy) redirected to 0x4c30da0 (__GI_stpcpy)
    --12291-- Reading syms from /lib/x86_64-linux-gnu/libnss_files-2.19.so
    --12291--   Considering /lib/x86_64-linux-gnu/libnss_files-2.19.so ..
    --12291--   .. CRC mismatch (computed 69b3fb24 wanted 71fe8a31)
    --12291--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libnss_files-2.19.so ..
    --12291--   .. CRC is valid
    --12291-- REDIR: 0x5692430 (libc.so.6:__GI_strcpy) redirected to 0x4c2e2a0 (__GI_strcpy)
    --12291-- REDIR: 0x569d7a0 (libc.so.6:rawmemchr) redirected to 0x4c319f0 (rawmemchr)
    --12291-- REDIR: 0x5746de0 (libc.so.6:__strcasecmp_avx) redirected to 0x4c2ea80 (strcasecmp)
    *** stack smashing detected ***: ./ZmqProject terminated
    ==12291== 
    ==12291== Process terminating with default action of signal 6 (SIGABRT)
    ==12291==    at 0x5640C37: raise (raise.c:56)
    ==12291==    by 0x5644027: abort (abort.c:89)
    ==12291==    by 0x567D2A3: __libc_message (libc_fatal.c:175)
    ==12291==    by 0x5714BBB: __fortify_fail (fortify_fail.c:38)
    ==12291==    by 0x5714B5F: __stack_chk_fail (stack_chk_fail.c:28)
    ==12291==    by 0x401D32: main (in /home/fds/Scrivania/ClientProgram/build/ZmqProject)
    --12291-- Discarding syms at 0x74ff2a0-0x7504eb3 in /lib/x86_64-linux-gnu/libnss_files-2.19.so due to munmap()
    ==12291== 
    ==12291== HEAP SUMMARY:
    ==12291==     in use at exit: 0 bytes in 0 blocks
    ==12291==   total heap usage: 767 allocs, 767 frees, 176,711 bytes allocated
    ==12291== 
    ==12291== All heap blocks were freed -- no leaks are possible
    ==12291== 
    ==12291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    ==12291== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    Aborted (core dumped)
    

* * *

**`EDIT 2`** \- Today I tried to compile my c++ code using `g++` not `CMake`
as before.

    
    
    g++ -o client_cpp client_cpp.cpp -lzmq
    

Now c++ client - python server **works**!

**`Q2:`** How can I change `CMakeLists.txt` to be sure that my code can work
with it?

I need to use **`CMAKE`**

**`EDIT 3`** How can I "traslate" the following command line into
`CMakeLists.txt`?

    
    
    g++ -o client_cpp client_cpp.cpp -lzmq
    


Answer: ## `Step 0:` isolate the sweet-spot

As proposed in comments above, kindly update, **run** & **post** output from a
trivial self-diagnosing code modification:

    
    
       int main ()
       {
          zmq::context_t context (1);
       // std::cout << "[1] .... + errno; // ----------------------------[1]
    
          zmq::socket_t socket (context, ZMQ_REQ);
       // std::cout << "[2] .... + errno; // ----------------------------[2]
    
          std::cout << "Connecting to hello world server…" << std::endl;
          socket.connect ("tcp://localhost:5555");
       // std::cout << "[3] .... + errno; // ----------------------------[3]
    
          std::string message = "hello";
          zmq::message_t request (message.size());
       // std::cout << "[4] .... + errno; // ----------------------------[4]
    
          memcpy (request.data (), (message.c_str()), (message.size()));
       // std::cout << "[5] .... + errno; // ----------------------------[5]
    
          socket.send (request);
       // std::cout << "[6] .... + errno; // ----------------------------[6]
    
          return 0;
       }
    

## `Step 1:` [re-read the `ZeroMQ API` details](http://api.zeromq.org/) for
interpreting the _errno_

`ZeroMQ` team has put a remarkable effort to API documentation and you can
only benefit from reading full details + debugging tips contained there.

As you will learn there, **_errno_** is typically associated with **_rc_**
return-codes, so as to increase contex-specific state-resolution strategies in
states, when API-service calls run into (non)-standard situations.

## Example:  ...ØMQ team is particularly smart & pedantic on this since early
releases- kudos

> The **`zmq_send()`** function shall return number of bytes in the message if
> successful. Otherwise it shall return **`-1`** and set **_errno_** to one of
> the values defined below.  
>  
> **Errors**  
>  
>  **`EAGAIN`** Non-blocking mode was requested and the message cannot be sent
> at the moment.  
>  
> **`ENOTSUP`** The `zmq_send()` operation is not supported by this socket
> type.  
>  
> **`EFSM`** The `zmq_send()` operation cannot be performed on this socket at
> the moment due to the socket not being in the appropriate state. This error
> may occur with socket types that switch between several states, such as
> `ZMQ_REP`. See the messaging patterns section of `zmq_socket(3)` for more
> information.  
>  
> **`ETERM`** The ØMQ context associated with the specified socket was
> terminated.  
>  
> **`ENOTSOCK`** The provided socket was invalid.  
>  
> **`EINTR`** The operation was interrupted by delivery of a signal before the
> message was sent.  
>  
> **`EHOSTUNREACH`** The message cannot be routed.
    
    
    /*                                                     Send a multi-part
                                                           message consisting
                                                           of three parts to socket */
    rc = zmq_send ( socket, "ABC",   3, ZMQ_SNDMORE );     assert (rc == 3);
    rc = zmq_send ( socket, "DEFGH", 5, ZMQ_SNDMORE );     assert (rc == 5);
    
    /*                                                     Final part;
                                                           no more parts to follow */
    rc = zmq_send ( socket, "JK",    2, 0 );               assert (rc == 2);
    

## `Step 2:` review the root cause of the failed call

Without the posted output from `**`Step 0`**` there is no chance to proceed to
learn **_Why_** , so please start with this one with a reasonable certainty
that it will isolate the exact location **_Where_** the panic-state has
originated.

This helps everybody ( incl. here ) to move to re-interpreting the `**`Step
1`**` for answering **_Why_**.

## `Always:` take due care for resources release & termination

Distributed systems' architectures are not as trivial as demo examples show. A
unifying design practice is that you - the programme designer - are
responsible end-to-end for all primary functions plus also for all blocking /
panic states, inti which the distributed system, or any it's smaller part, can
get into including the final release of each resource that was (dynamically)
allocated anywhere in the distributed system. Complex? Sure. Demanding? Sure.
Self-discipline self-dictatorship? Always.

This goes a lot beyond the O/P scope, but while python hides many resource-
management duties from user-programming, other language bindings / wrappers
need not be so generous.

**Always** prepare, including via handled exceptions, ZeroMQ-socket resources
to `.close()` in a non-blocking mode ( `LINGER = 0` ).

**Always** explicitly, including via handled exceptions, `.close()` ZeroMQ-
sockets before ending the code.

**Always** explicitly, including via handled exceptions, release all hidden
IO-threads factory by **`.term()`** the ZeroMQ **`Context`** instance.

