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 <[email protected]> >>>>> 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 >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>> >>>>> _______________________________________________ >>>>> zeromq-dev mailing list >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>> >> >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
