¿Qué podría estar causando este bloqueo en libzmq.dll?

I have an x64 C# application running on the .NET Framework 4.0 x64, which uses the clrzmq-x64 2.2.2 (from NuGet) for CeroMQ.

It's working fine when I debug it (i.e.F5) but it only sends about 30 messages a second. If I don't attach the debugger (i.e. CTRL-F5) it manages over 1000 messages a second... but it crashes after about 30 seconds.

I'm having trouble diagnosing the problem because the point where it crashes isn't in my code.

I've pasted all the information I can find that might be useful, but I'm struggling to know how to interpret the stack trace.

Registro de eventos:

Faulting application name: MyApplication.exe, version: 1.0.0.0, time stamp: 0x4f5a05b3
Faulting module name: MSVCR100.dll, version: 10.0.40219.325, time stamp: 0x4df2bcac
Exception code: 0x40000015
Fault offset: 0x00000000000761c9
Faulting process id: 0x273c
Faulting application start time: 0x01ccfdf8acdc087e
Faulting application path: [path redacted]\MyApplication.exe
Faulting module path: C:\Windows\system32\MSVCR100.dll
Report Id: f3518caf-69eb-11e1-9ed1-50e549e1c0d9

Seguimiento de pila:

msvcr100.dll!__crt_debugger_hook()  
msvcr100.dll!_call_reportfault()  + 0x124 bytes 
msvcr100.dll!abort()  + 0x35 bytes  
libzmq.dll!zmq::signaler_t::make_fdpair(unsigned __int64 * r_=0x000000002c557ee0, unsigned __int64 * w_=0x000007feedcb7ad2)  Line 263   C++
libzmq.dll!zmq::signaler_t::signaler_t()  Line 80   C++
libzmq.dll!zmq::mailbox_t::mailbox_t()  Line 26 + 0x17 bytes    C++
libzmq.dll!zmq::socket_base_t::socket_base_t(zmq::ctx_t * parent_=0x0000000027e3e470, unsigned int tid_=4294967294)  Line 124 + 0x6b bytes  C++
libzmq.dll!zmq::push_t::push_t(zmq::ctx_t * parent_=0x0000000076e3e3db, unsigned int tid_=0)  Line 30 + 0xe bytes   C++
libzmq.dll!zmq::socket_base_t::create(int type_=43532552, zmq::ctx_t * parent_=0x0000000002984130, unsigned int tid_=43532512)  Line 100 + 0x29 bytes   C++
libzmq.dll!zmq::ctx_t::create_socket(int type_=489832384)  Line 184 + 0xe bytes C++
clr.dll!DoNDirectCall__PatchGetThreadCall()  + 0x7b bytes   
000007ff00168461()  
000007ff0016833f()  
000007ff00166b22()  
000007ff00166997()  
mscorlib.ni.dll!000007fef4669e70()  
[Frames below may be incorrect and/or missing, no symbols loaded for mscorlib.ni.dll]   
00000000030bd4c0()  
0000000027e3e9c8()  
mscorlib.ni.dll!000007fef4094568()  
clr.dll!JIT_IsInstanceOfAny()  + 0x20 bytes 
mscorlib.ni.dll!000007fef465e56b()  
00000000030bd560()  
00000000006f8d10()

preguntado el 09 de marzo de 12 a las 13:03

2 Respuestas

Es https://github.com/zeromq/libzmq/pull/491.

Basically, on a busy Windows system, in which many ZMQ sockets are frequently created and destroyed, creation of a socket implies creation of a pair of internal sockets, and this might fail with the same stack you show above. What's worse, on a non-debug build the exception causes the socket creation code to abandon a taken critical section, which then causes subsequent attempts at socket creation to hang forever.

The link above has a fix that we are testing as I type this.

Respondido 05 Abr '13, 13:04

The fix works as expected. We can't see anymore these failures while creating sockets nor we see create_socket hanging forever afterwards. - gabriele giuseppini

Is it possible you are creating new sockets all the time ? In that case try to setup the context and the sockets once and reuse them.

respondido 10 mar '12, 05:03

I'm using a shared Context but creating multiple Sockets in different Tasks. If I share the Socket then a REQ/REP with framed messages doesn't work because one Task might be trying to Send() or SendMore() on that socket while another is calling Recv(). I guess I need a way of limiting the Sockets to a pool so I don't hit this limit. - tom Robinson

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.