[zeromq-dev] zmq socket monitor goes wrong?

Ondrej Kupka ondra.cap at gmail.com
Wed May 22 14:45:45 CEST 2013


On May 22, 2013, at 2:20 PM, Ondrej Kupka wrote:

> 
> On May 22, 2013, at 2:14 PM, Ondrej Kupka wrote:
> 
>> 
>>> Hmm, but addr is a pointer, so I don't really that the ownership of the data. But I thought that https://github.com/tchap/gozmq-utils/blob/master/monitor.go#L188 copies the data… Will have to check to be sure…
>>> 
>> 
>> But anyway, I checked it using printf right in C and it was the same mess. I don't see right now what is the ownership issue. But I will probably have to dig into sources more to understand how things are or are not copied/passed around…
>> 
> 
> Ah, overlooked the test case link you sent, I will continue researching myself I guess…
> 
> Thanks and sorry for spamming a bit O:-)
> 
> Ondra
> 
>> Ondra
>> 
>>> On May 22, 2013, at 2:05 PM, Ondrej Kupka wrote:
>>> 
>>>> Hi Lourens,
>>>> 
>>>> Thanks for the reply.
>>>> 
>>>> I am not sure that this is the problem. It works in the following way:
>>>> 
>>>>     1. Receive frames in Go by calling gozmq.Socket.RecvMultipart(). This already copies the data (Go takes the ownership).
>>>>     2. Pass it to the C function parse_socket_event(), which is "generated" at compile time to work with either zeromq3-x events protocol (single frame containing a struct) or libzmq events protocol (2 frames). Fill in malloc'd gzu_socket_event_t, which is the same for both protocols.
>>>>     3. Pass the gzu_socket_event_t pointer back to Go and use it further. Then free it by calling free from Go.
>>>> 
>>>> Now the bottom line is that the event struct is just a frame of data received before and is thus in my (Go) ownership and is garbage-collected by Go later, so this can't be the issue.
>>>> 

Found the issue. In fact I cannot receive a struct containing a pointer using gozmq, because they copy the data, release the message, but of course the addr is not copied, so I am in fact accessing memory that is not mine. You were right all this time, Lourens :-)

Have a nice day,
Ondra

>>>> But it is possible that I am mistaken :-)
>>>> 
>>>> Thanks again,
>>>> Ondra
>>>> 
>>>> On May 22, 2013, at 1:22 PM, Lourens Naudé wrote:
>>>> 
>>>>> Hi Ondra,
>>>>> 
>>>>> Afaik you'd need to memcpy the data - from the event struct as it can be free'd from within libzmq in nondeterministic fashion and thus https://github.com/tchap/gozmq-utils/blob/master/parse_socket_event.c#L51-L52 won't work. See the test cases in libzmq for an example :
>>>>> 
>>>>> https://github.com/zeromq/libzmq/blob/master/tests/test_monitor.cpp#L55
>>>>> 
>>>>> On Wed, May 22, 2013 at 11:50 AM, Ondrej Kupka <ondra.cap at gmail.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> I am working on zmq_socket_monitor bindings + some abstractions for Go. I am almost there, but I am getting very weird results when I run my tests (one large test for now to be honest). You can see the output at http://pastebin.com/kqgjLFyt. As you can see, only once out of ten runs of the tests, event addr is filled in properly.
>>>>> 
>>>>> I am not sure what is happening, but I am pretty sure that I am getting this from libzmq (gozmq) and I am not breaking it anywhere in my Go. In any case, you can check sources at https://github.com/tchap/gozmq-utils, the C part is at https://github.com/tchap/gozmq-utils/blob/master/parse_socket_event.c
>>>>> 
>>>>> If you find any silly mistake of mine, please let me know, otherwise it is probably a libzmq bug…
>>>>> 
>>>>> Thanks in advance,
>>>>> Ondra Kupka
>>>>> _______________________________________________
>>>>> 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
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130522/0e0b1e32/attachment.htm>


More information about the zeromq-dev mailing list