stack over flow on windows x64

[crinai]

Please use this template for reporting suspected bugs or requests for help.

Issue description

socket on windows is different from it on linux, the struct is a little bigger, needs more stack size to work
normal.
Change the link option to increase the stack size can solve it ,but it's not working if the program it desined as a DLL to be loaded by anthoer EXE

Environment

Microsoft Visual Studio 2010

• libzmq version (commit hash if unreleased):
  v4.2.3
• OS:
  Windows 7 x64 , Windows 10 x64

Minimal test code / Steps to reproduce the issue

1. build the example "inproc_thr" in x64
2. set any args run the program
3. run,and it will crash

What's the actual result? (include assertion message & call stack if applicable)

inproc_thr.exe!__chkstk()	未知

inproc_thr.exe!std::map<unsigned short,zmq::select_t::family_entry_t,std::less,std::allocator<std::pair<unsigned short const ,zmq::select_t::family_entry_t> > >::operator 行 210 C++
inproc_thr.exe!zmq::select_t::add_fd() 行 80 C++
inproc_thr.exe!zmq::socket_base_t::start_reaping() 行 1330 C++
inproc_thr.exe!zmq::reaper_t::process_reap() 行 128 C++
inproc_thr.exe!zmq::object_t::process_command() 行 143 C++
inproc_thr.exe!zmq::reaper_t::in_event() 行 98 C++
inproc_thr.exe!zmq::select_t::trigger_events() 行 122 C++
inproc_thr.exe!zmq::select_t::select_family_entry() 行 404 C++
inproc_thr.exe!zmq::select_t::loop() 行 372 C++
inproc_thr.exe!zmq::select_t::worker_routine() 行 416 C++
inproc_thr.exe!thread_routine() 行 47 C++
inproc_thr.exe!_callthreadstartex() 行 314 C
inproc_thr.exe!_threadstartex(void * ptd) 行 297 C
kernel32.dll!00007ffa41982774() 未知
ntdll.dll!00007ffa44150d51() 未知

What's the expected result?

increase the stack size,there is two way:
1.roperties - Configuration Properties - Linker - System - Stack Reserve Size
2.edit the src/thread.cpp file(line 59):
from:
descriptor = (HANDLE) _beginthreadex (NULL, 0,
&::thread_routine, this, 0 , NULL);
to:
descriptor = (HANDLE) _beginthreadex (NULL, 41943040,
&::thread_routine, this, 0 , NULL);

[bluca]

libzmq/INSTALL

Line 49 in 4e20c45

In VS 2012 it is mandatory to increase the default stack size of 1 MB to

[bluca]

no answer, assuming problem is solved with instructions from readme, closing

[masariello]

This problem has been hitting us for a while now. Depending on how deep the stack is at the point ZMQ is called, we would get stack overflows "raised" by __stkchk() in the Visual C++ run-time.

Our targets are DLLs so we cannot change the size of the stack on which ZMQ gets called. Sure, we could re-engineer our code to spin a thread with a large stack just to call ZMQ, but that would be a rather intrusive change. It's a bit of a heavy handed requirement for ZMQ to impose on client code.

In our case the stack overflow was happening in zmq::signaler_t::wait, so I changed it to allocate the fd_set (*) it uses on the heap instead of the stack. This has solved the specific issue, but obviously there are a number of places in ZMQ that allocate fd_set's on the stack and will be prone to the same issue.

I'm happy to put a patch together, but allocating fd_set's on the heap will incur a little performance hit in ZMQ. Would this be acceptable?

(*) sizeof(fd_set) = 128KB on win64

[bjovke]

@masariello As a quick fix you can decrease the FD_SETSIZE for which default value is 16384 and rebuild everything. Of course, you can do this if you don't expect that your application will ever use this many sockets.

fd_sets in some functions were actually allocated on heap some time ago and it was changed to stack for performance reasons. You can maybe try to do some benchmark to compare performance of the two versions (heap and stack allocation)?

The stack overflow in this issue happened in std::map containing fd_sets. It seems that prior to Visual Studio 2013 std::map::operator[] internally does some copying and it allocates twice more fd_sets on stack. Take a look at #2344.

Which compiler are you using to build?

[masariello]

We use VS2015

master has already fixed this problem in socket_poller_t by introducing optimized_fd_set_t. I put in a little PR to extend the fix to signaler_t::wait.

[reasoning]

This issue should not be closed.

Its quite difficult to work around if for instance you are the author of a DLL and don't therefore control the default stack size of the executable and your also using ZMQ as a DLL.

Why not apply the trivial patch below to the ZMQ thread start function on windows so that at the very least 64 bit users of older MSVC versions can still use the library.

In thread.cpp line ~57

void zmq::thread_t::start (thread_fn *tfn_, void *arg_, const char *name_)
{
tfn = tfn;
arg = arg;
if (name_)
strncpy (name, name, sizeof (_name) - 1);

// Set default stack size to 4MB - 0x400000 to avoid std::map stack overflow on x64
unsigned int stack = 0;
#if defined _WIN64
stack = 0x400000;
#endif
#if defined _WIN32_WCE
_descriptor =
(HANDLE) CreateThread (NULL, stack, &::thread_routine, this, 0, NULL);
#else
_descriptor =
(HANDLE) _beginthreadex (NULL, stack, &::thread_routine, this, 0, NULL);
#endif
win_assert (_descriptor != NULL);
_started = true;
}