[zeromq-dev] zmq::mtrie_t::rm_helper(..)

[Pau]

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
>