[zeromq-dev] zmq::mtrie_t::rm_helper(..)
Pau
pau at teleopsia.com
Fri Mar 22 17:37:15 CET 2013
All this thread was a mistake, sorry about that.
What is actually happening in my application is that receiving an
ZMQ_UNSUBSCRIBE in a socket that perhaps never received the
corresponding ZMQ_SUBSCRIBE a zmq_assert is triggered.
[mtrie.cpp]
bool zmq::mtrie_t::rm_helper (unsigned char *prefix_, size_t size_,
pipe_t *pipe_)
{
if (!size_) {
if (pipes) {
pipes_t::size_type erased = pipes->erase (pipe_);
zmq_assert (erased == 1); <============================
if (pipes->empty ()) {
delete pipes;
pipes = 0;
}
}
return !pipes;
}
I have several applications publishing and several subscribing, both
cases use one socket so when subscriber subscribes it is connected to
various publishers and when unsubscribes also. I use PUB/SUB.
Is there any limitation?
I am facing some stress on that, so if someone has a clue about what
generates the assert or waht I am missing I would highly appreciate.
Thanks.
El 19/03/2013 11:41, Pau escribió:
> I am still facing a hang in Windows XP with Publish/Subscribe.
>
> I have not been capable to do a test case to reproduce it properly but I
> have some data and some questions.
>
> What is crashing (I am getting the info from a release build debugging
> sesion, so data info is not reliable but the stack is):
>
> A server application is calling zmq::socket_base_t::send (msg_t *msg_,
> int flags_) to publish a message from a PUB socket
> process_commands (0, true) is called
> cmd.destination->process_command (cmd) is called
> process_bind (cmd_.args.bind.pipe) is called
> attach_pipe (pipe_) is called
> xattach_pipe (pipe_, icanhasall_) is called
> xread_activated (pipe_) is called
> subscriptions.rm (data + 1, size - 1, pipe_) is called
> From here zmq::mtrie_t::rm_helper (unsigned char *prefix_, size_t
> size_, pipe_t *pipe_) is recursively called with prefix_ forming a
> sequence of characters that coincide withe a subscription that was made
> by a client. The last call (when size is 0) crashes because this == NULL.
>
> It is not clear to me how this can happen because when rm_helper(..)
> calls himself in next_node->rm_helper (..) it checks next_node not to
> be NULL.
>
>
> Question:
> How the node can become NULL (in the stack there is no trace of a
> function that NULLs anything).
>
> I will keep on trying to make a test case but in the inbetween I am in
> trouble. We have a number of applications publishing and all them crash
> at the same time.
>
> thanks,
>
> Pau
>
>
> El 05/03/2013 16:42, Pau escribió:
>> I have found that this happens after subscribing from a pub many (4)
>> times to the same string. I have changed the subscriber and now I do not
>> see the crash in the publisher.
>>
>> I am trying to narrow the problem better.
>>
>> I leave the stack in case it gives any clue.
>>
>>
>> libzmq.dll!zmq::mtrie_t::rm_helper(unsigned char *
>> prefix_=0x0372e1d8, unsigned int size_=0, zmq::pipe_t *
>> pipe_=0x10023fb4) Línea 293 C++
>> libzmq.dll!zmq::mtrie_t::rm_helper(unsigned char *
>> prefix_=0x3072e1d7, unsigned int size_=1, zmq::pipe_t *
>> pipe_=0x038e9780) Línea 311 + 0x16 bytes C++
>> libzmq.dll!zmq::mtrie_t::rm_helper(unsigned char *
>> prefix_=0x3072e1d6, unsigned int size_=2, zmq::pipe_t *
>> pipe_=0x038e9780) Línea 311 + 0x16 bytes C++
>> libzmq.dll!zmq::mtrie_t::rm_helper(unsigned char *
>> prefix_=0x3172e1d5, unsigned int size_=3, zmq::pipe_t *
>> pipe_=0x038e9780) Línea 311 + 0x16 bytes C++
>> libzmq.dll!zmq::xpub_t::xread_activated(zmq::pipe_t *
>> pipe_=0x038e9780) Línea 69 C++
>> > libzmq.dll!zmq::xpub_t::xattach_pipe(zmq::pipe_t *
>> pipe_=0x038e9780, bool icanhasall_=false) Línea 53 + 0xa bytes C++
>> libzmq.dll!zmq::socket_base_t::attach_pipe(zmq::pipe_t *
>> pipe_=0x038e9780, bool icanhasall_=false) Línea 233 C++
>> libzmq.dll!zmq::socket_base_t::process_bind(zmq::pipe_t *
>> pipe_=0x038e9780) Línea 854 + 0xe bytes C++
>> libzmq.dll!zmq::object_t::process_command(zmq::command_t &
>> cmd_={...}) Línea 92 C++
>> libzmq.dll!zmq::socket_base_t::process_commands(int timeout_=0,
>> bool throttle_=true) Línea 826 C++
>> libzmq.dll!zmq::socket_base_t::send(zmq::msg_t * msg_=0x0372e518,
>> int flags_=3) Línea 614 C++
>> libzmq.dll!zmq_sendmsg(void * s_=0x02b5e068, zmq_msg_t *
>> msg_=0x0372e518, int flags_=3) Línea 346 + 0x2b bytes C++
>> BoxDu.exe!zmq::socket_t::send(zmq::message_t & msg_={...}, int
>> flags_=3) Línea 376 + 0x16 bytes C++
>> BoxDu.exe!zmsg::send(zmq::socket_t & socket={...}) Línea 148 +
>> 0x32 bytes C++
>> BoxDu.exe!zmqMajordomo::mdbroker::actor_process(std::basic_string<char,std::char_traits<char>,std::allocator<char>
>> > & sender="101410101", zmsg * msg=0x0496d068) Línea 810 C++
>> BoxDu.exe!zmqMajordomo::mdbroker::brokering() Línea 124 + 0x16
>> bytes C++
>> BoxDu.exe!V3ActorBroker::poll() Línea 164 C++
>> BoxDu.exe!V3ActorThread::Run() Línea 95 + 0x17 bytes C++
>> BoxDu.exe!V3_Thread::Wrapper(void * pv=0x0333e718) Línea 32 + 0xf
>> bytes C++
>> kernel32.dll!7c80b729()
>>
>>
>> El 05/03/2013 16:00, Charles Remes escribió:
>>> Doesn't ring a bell for me.
>>>
>>> A few questions…
>>>
>>> Are all endpoints using 3.2.2 or is it a mix of 3.2.2 and 2.2?
>>>
>>> What transports are you using (inproc, tcp, ipc)?
>>>
>>> Are you using XPUB and XSUB directly or are the endpoints actually PUB/SUB but you are seeing a crash in the parent?
>>>
>>> How many subscriptions do you have on each endpoint?
>>>
>>> Are there any intermediate devices between the edge endpoints (e.g. a FORWARDER device)?
>>>
>>> Any chance you can use a Windows OS that is not EOL? :)
>>>
>>> cr
>>>
>>> On Mar 5, 2013, at 8:55 AM, Pau <pau at teleopsia.com> wrote:
>>>
>>>> Hi, they have found today 2 servers publishing using xsub crashed in
>>>> mtrie.cpp[line 293] in function zmq::mtrie_t::rm_helper(..) line
>>>> apparently tryng to acces if (pipes->empty ()). I guess pipes was rubish
>>>> but I could not debug and I have been unable to reproduce at the moment.
>>>> The function was called from xpub_t when publishing a message. It
>>>> happened at the same time in 2 apps in the same machine but unrelated.
>>>>
>>>> We work with 3.2.2 in Windows XP in an environment where there are like
>>>> 5 o 6 different sockets per application and arounf 5 or 6 normally on. I
>>>> am trying to provoque it back to make a test case but at the moment I
>>>> couldn't.
>>>>
>>>> Rings a bell to anybody?,
>>>>
>>>> thanks,
>>>>
>>>> Pau Ceano
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
More information about the zeromq-dev
mailing list