You can enable Stop on All Exceptions on Dev2012 and run your process.
As soon as an exception happens, it will stop on that instructions and you
will be able to see the stack and environment variables for all frames,
which may help you find out what is wrong.
If you install the WinDBG debugger ("Debugging Tools For Windows"
<https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx>),
there is a tool called ADPLUS that can be used to script a debugging
session that attaches to your process and generate minidumps of the
exceptions it encounters (includes crash dumps). This is useful if you will
send the minidump to somebody else to analyze for you. With it comes a
adplus.doc file that explains how to use the tool.
One would need the same WinDBG and open it with these commands:
CMD> windbg.exe -k minidump.dmp
windbg>.ecxr
windbg>kvn
windbg>dv
windbg>.frame 1
windbg>dv
windbg>.frame 2
windbg>dv
winsbg>q
These commands above would:
.ecxr - search in the saved minidump for the stack where the exception was
recorded.
kvn - show the stack at that time of the exception starting with a stack
frame number for each line
dv - show the local (stack) variables for the current frame
.frame n - changes the frame to nth line
q - quit the (minidump) debugging session
qd - if you ever debugging a live process that should not be killed when
the WinDBG exists, use qd to "detach and quit"
On Wed, Nov 30, 2016 at 1:37 PM Robin Scher <ro...@uberware.net> wrote:
> For testing purposes, no I am creating the context, creating the socket
> and binding the socket from a single thread (the main thread). There are
> other threads in my process, but none that interact with the ZeroMQ
> objects. I have not build a minimal sample to reproduce yet. Once this is
> resolved, my original code does pass the socket between threads, using a
> mutex to ensure that it is only accessed from a single thread, but I am not
> using that at the moment for testing.
>
> The crash happens just after the main thread calls zmq_bind. There are no
> other uses of the socket object, for testing purposes, once it gets bound,
> the main thread just goes into an infinite loop that does nothing at all.
> No other thread is using any part of zmq for any purpose, and no other
> process is running that is trying to connect to this open socket or send
> any data to it.
>
> Thanks for any other help anyone can provide.
> -robin
>
> Robin Scher | +1 (213) 448-0443 <(213)%20448-0443> |
> ro...@uberware.net | www.uberware.net
>
> -----Original Message-----
> From: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf
> Of Luca Boccassi
> Sent: Wednesday, November 30, 2016 3:42 AM
> To: ZeroMQ development list <zeromq-dev@lists.zeromq.org>
> Subject: Re: [zeromq-dev] ZMQ 4.2.0 stack overflow on Windows
>
> When you refer to main thread, are you by any chance creating a socket in
> a thread and using it from another?
>
> On Tue, 2016-11-29 at 13:54 -0800, Robin Scher wrote:
> > I am trying to update from 4.1.x to 4.2.0 for my project, and when I
> > run it linked to the 4.2.0 library, I get a stack overflow in a ZeroMQ
> > background thread when I bind a socket:
> >
> >
> >
> > MyProgram.exe!__chkstk() Line 117
> >
> > MyProgram.exe!std::map<unsigned
> > short,zmq::select_t::family_entry_t,std::less<unsigned
> > short>,std::allocator<std::pair<unsigned short const
> > ,zmq::select_t::family_entry_t> > >::operator[](const unsigned short &
> > _Keyval) Line 191
> >
> > MyProgram.exe!zmq::select_t::add_fd(unsigned __int64 fd_,
> > zmq::i_poll_events
> > * events_) Line 77
> >
> > MyProgram.exe!zmq::socket_base_t::start_reaping(zmq::select_t *
> > poller_) Line 1312
> >
> > MyProgram.exe!zmq::reaper_t::process_reap(zmq::socket_base_t *
> > socket_) Line
> > 128
> >
> > MyProgram.exe!zmq::object_t::process_command(zmq::command_t & cmd_)
> > Line 135
> >
> > MyProgram.exe!zmq::reaper_t::in_event() Line 98
> >
> > MyProgram.exe!zmq::select_t::loop() Line 318
> >
> > MyProgram.exe!zmq::select_t::worker_routine(void * arg_) Line 393
> >
> > MyProgram.exe!thread_routine(void * arg_) Line 47
> >
> > msvcr110d.dll!_callthreadstartex() Line 354
> >
> > msvcr110d.dll!_threadstartex(void * ptd) Line 337
> >
> > kernel32.dll!00007ffd243013d2() Unknown
> >
> > ntdll.dll!00007ffd246054e4() Unknown
> >
> >
> >
> > The executable has done nothing but create the context, create the
> > socket, set a few socket options, and then calls zmq_bind on it. The
> > issue does not happen in the main thread, and the main thread does not
> > report any errors or have any faults. No other client is running on
> > this or any networked machine that is trying to connect to the process
> yet.
> >
> >
> >
> > I am using MSVC 2012. Stack size is at the default.
> >
> >
> >
> > Any ideas of where I can look to resolve this? I would like to use the
> > current version of the library, if possible. Thank you,
> >
> > -robin
> >
> >
> >
> > Robin Scher | +1 (213) 448-0443 <(213)%20448-0443> | <mailto:
> ro...@uberware.net>
> > ro...@uberware.net | <http://www.uberware.net/> www.uberware.net
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
