Hello list.
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault. On the one
hand, it is possible to refer to an error because of the user. But on
the other hand, Coding Style says: Assertions say that the ØMQ
developers do not
On 11/02/2012, at 8:27 PM, niXman wrote:
>
> Continuing review of the libzmq code, I have found a few situations
> when the program will be crushed on segmentation fault.
It's impossible to avoid this in C.
> I consider that programs crash on segmentation fault is an
> inadmissible error of th
Just a progress note: example of output:
http://zguide.zeromq.org/page:all#Handling-Multiple-Sockets
[mspoller] Process Monitoring pthread for test/zmq/mspoller start at 1328944214
[mspoller] Process 15247 created for program test/zmq/mspoller
[msreader] Process Monitoring pth
2012/2/11 john skaller :
>
> On 11/02/2012, at 8:27 PM, niXman wrote:
>
>>
>> Continuing review of the libzmq code, I have found a few situations
>> when the program will be crushed on segmentation fault.
>
> It's impossible to avoid this in C.
>
>> I consider that programs crash on segmentation fa
On 11/02/2012, at 9:23 PM, niXman wrote:
> In the example above, it is enough to add check on null pointer ( if
> (optvallen_ && !(optval_)) {} ). This gives to the user more
> information about the error, instead of the silent crash.
Agreed.
> Regarding the check of pointers of sockets, everyt
2012/2/11 john skaller :
>
> On 11/02/2012, at 9:23 PM, niXman wrote:
>
>> In the example above, it is enough to add check on null pointer ( if
>> (optvallen_ && !(optval_)) {} ). This gives to the user more
>> information about the error, instead of the silent crash.
>
> Agreed.
>
>> Regarding the
On Sat, Feb 11, 2012 at 11:06 AM, niXman wrote:
>
> Meanwhile, even my simple patch [1] isn't accepted.
>
>
> [1] https://github.com/zeromq/libzmq/pull/240
>
... it's been a day. You need to consider resetting your expectations of
open source communities.
Ian
___
If an amount of sockets reduce to 500-1000, the error remains?
2012/2/11 Marcin Olak :
> Hi,
>
>> If you on linux system, run your program with strace: strace
>> executable -o logfile.log
>
> Last two requests processed by the worker thread that aborted the program:
>
>
>
> 10759 fcntl64(1847, F_
On 11/02/2012, at 10:06 PM, niXman wrote:
> Before writing something, I want to understand the attitude of the
> project Administrators to innovations, and their readiness to take
> measures for improving libzmq.
It's fairly clear in the policy.
> Meanwhile, even my simple patch [1] isn't acce
2012/2/11 john skaller :
>
> On 11/02/2012, at 10:06 PM, niXman wrote:
>
>> Before writing something, I want to understand the attitude of the
>> project Administrators to innovations, and their readiness to take
>> measures for improving libzmq.
>
> It's fairly clear in the policy.
>
>> Meanwhile,
On Feb 11, 2012, at 5:06 AM, niXman wrote:
> Before writing something, I want to understand the attitude of the
> project Administrators to innovations, and their readiness to take
> measures for improving libzmq.
> Meanwhile, even my simple patch [1] isn't accepted.
>
>
> [1] https://github.com
2012/2/11 Chuck Remes :
> On Feb 11, 2012, at 5:06 AM, niXman wrote:
>
>> Before writing something, I want to understand the attitude of the
>> project Administrators to innovations, and their readiness to take
>> measures for improving libzmq.
>> Meanwhile, even my simple patch [1] isn't accepted.
Good morning,
On Feb 11, 2012, at 01:51 , john skaller wrote:
> On 11/02/2012, at 8:27 PM, niXman wrote:
[...]
>> Continuing review of the libzmq code, I have found a few situations
>> when the program will be crushed on segmentation fault.
>
> It's impossible to avoid this in C.
That's bollocks
On Feb 11, 2012, at 10:53 AM, John D. Mitchell wrote:
> On Feb 11, 2012, at 01:51 , john skaller wrote:
>> On 11/02/2012, at 8:27 PM, niXman wrote:
> [...]
>>> Continuing review of the libzmq code, I have found a few situations
>>> when the program will be crushed on segmentation fault.
>>
>> It'
On Sat, Feb 11, 2012 at 12:37 PM, Chuck Remes wrote:
> On Feb 11, 2012, at 10:53 AM, John D. Mitchell wrote:
>
>> On Feb 11, 2012, at 01:51 , john skaller wrote:
>>> On 11/02/2012, at 8:27 PM, niXman wrote:
>> [...]
Continuing review of the libzmq code, I have found a few situations
when
Hi all!
I posted this question about a week ago, but it was fairly long-winded, and
there was some other deep, heated discussion going on so I thought I'd give it
one more shot. I hope I'm not offending the etiquette of the mailing list by
re-posting, but if so, my apologies, and I won't do it
On Fri, Feb 10, 2012 at 9:15 PM, Wes Young wrote:
> that whole idea around "removing devices from zmq3" thing, is pretty much
> wrapped up in libzfl? no?
Yes, and zdevices. zfl needs cleaning up because a lot of the core was
refactored into CZMQ. But I think it's sensible, a richer library on
t
On Sat, Feb 11, 2012 at 7:40 AM, Marcin Olak wrote:
> Hi guys,
>
> In my system under heavy load and heavy socket creation/destruction an
> assertion
> in mailbox.cpp:84 (zeromq-2.1.11) aborts the program. Any clues why this might
> hapenning?
Sounds like a race condition on the pipe code. I bac
On Sat, Feb 11, 2012 at 6:27 PM, niXman wrote:
> For example the call:
>>rc = zmq_setsockopt (sub, ZMQ_SUBSCRIBE, 0, 4);
> will end on segmentation fault on line 56 of the sub.cpp file.
>
> According to the documentation, if an error occurs, the function
> should return -1.
>
> I can not decide h
On Sat, Feb 11, 2012 at 2:00 AM, Aja Walker wrote:
> Briefly, I'm occasionally seeing big, as in 10 milliseconds, end-to-end
> latencies on my Windows 7 machine, but not on my Linux machine.
No-one minds if you repost important questions.
Bad latencies are usually due to contention over CPU.
I'm confused ...
Do you all agree with that the arguments must be checked? And with the
fact that in case of error of arguments is not necessary to use assert
but set errno and return -1?
2012/2/11 Pieter Hintjens :
> On Sat, Feb 11, 2012 at 6:27 PM, niXman wrote:
>
>> For example the call:
>>>
On 12/02/2012, at 3:53 AM, John D. Mitchell wrote:
> Good morning,
>
> On Feb 11, 2012, at 01:51 , john skaller wrote:
>> On 11/02/2012, at 8:27 PM, niXman wrote:
> [...]
>>> Continuing review of the libzmq code, I have found a few situations
>>> when the program will be crushed on segmentation
lol:
"To make the C examples easier to write and read, I've taken the hash and list
container classes from the ZFL project, and renamed them as [zlist and zhash,
as we did with zmsg. In any modern language you can of course use built-in
containers."
yea, i literally *just* got to that point :)
On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
> I will aggressively merge patches that make 0mq a safer and more "forgiving"
> library.
No you won't :)
You want a robust check? I can give you 99.%.
But you'll pay.
You already griped about the tiny weeny cost of my thread safe
sockets (two
The problem with dangling pointers can only be solved using its own
allocator. Thus, any address (pointer), not found among the selected
blocks - is considered hanging.
This, in its turn will not only reduce the number of errors, but that
is not unimportant - will increase system reliability and wi
On 12/02/2012, at 6:47 AM, niXman wrote:
> I'm confused ...
> Do you all agree with that the arguments must be checked? And with the
> fact that in case of error of arguments is not necessary to use assert
> but set errno and return -1?
IMHO, if you do a check for a NULL pointer you should use a
On 12/02/2012, at 7:21 AM, niXman wrote:
> The problem with dangling pointers can only be solved using its own
> allocator.
Sort of. You don't need to actually write an allocator.
It is enough to trace all constructed sockets.
This won't stop memory corruption of a legitimately constructed
live
On Feb 11, 2012, at 1:47 PM, niXman wrote:
> I'm confused ...
> Do you all agree with that the arguments must be checked? And with the
> fact that in case of error of arguments is not necessary to use assert
> but set errno and return -1?
I think this is reasonable. If the community doesn't like
On Feb 11, 2012, at 2:14 PM, john skaller wrote:
>
> On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
>
>> I will aggressively merge patches that make 0mq a safer and more "forgiving"
>> library.
>
> No you won't :)
>
> You want a robust check? I can give you 99.%.
> But you'll pay.
John, w
2012/2/12 john skaller :
>
> On 12/02/2012, at 7:21 AM, niXman wrote:
>
>> The problem with dangling pointers can only be solved using its own
>> allocator.
>
> Sort of. You don't need to actually write an allocator.
> It is enough to trace all constructed sockets.
And what to do with pointers to
On 12/02/2012, at 7:44 AM, Chuck Remes wrote:
> On Feb 11, 2012, at 2:14 PM, john skaller wrote:
>
>>
>> On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
>>
>>> I will aggressively merge patches that make 0mq a safer and more
>>> "forgiving" library.
>>
>> No you won't :)
>>
>> You want a robu
On 12/02/2012, at 8:03 AM, niXman wrote:
>>
>> Sort of. You don't need to actually write an allocator.
>> It is enough to trace all constructed sockets.
>
> And what to do with pointers to the data for zmq_recv (), for example?
>
> void *data = 0x3423e65;
> zmq_recv(sock, data, 32, 0);
Of cour
On Sun, Feb 12, 2012 at 5:10 AM, Wes Young wrote:
> I cleaned zfl up a little yesterday (in a fork). Only really needed to remove
> zthread since it's in czmq, other than that it compiled a-OK.
Send a pull request when you can, it's great that zfl is coming back
to life. It was just waiting for
On Sun, Feb 12, 2012 at 4:47 AM, niXman wrote:
> Do you all agree with that the arguments must be checked? And with the
> fact that in case of error of arguments is not necessary to use assert
> but set errno and return -1?
Up to a point. Some invalid arguments are best handled with an
assertion
On Feb 11, 2012, at 3:15 PM, john skaller wrote:
>
> On 12/02/2012, at 7:44 AM, Chuck Remes wrote:
>>
>> John, why do you make this more complex than it needs to be?
>
> I'm making a point. There are alternate viewpoints,
> and compromises in between. Both viewpoints are valid,
> as are compro
Rough outline of proposal to fix the bad choice of socket type.
(And possibly others like contexts).
1. Change the docs to name the type zmq_socket_t
2. Add two macros
ZMQ_TYPE_SAFE
ZMQ_TYPE_UNSAFE
3. In the C binding:
if exactly one of these is set, use that
if two are set, bu
On 12/02/2012, at 9:04 AM, john skaller wrote:
[]
Ok, this is done. To use the patch (when it's pulled) convert your code to use
zmq_socket_t
zmq_ctx_t
instead of void*. in 3.x, these are defined to void * anyhow.
To check you code, do this:
#define ZMQ_EMULATE_TYPE_SAFE
#include
The compil
On Feb 11, 2012, at 4:53 PM, Pieter Hintjens wrote:
>
> So in my libraries, like CZMQ, I validate input arguments with
> asserts, systematically.
And yet for some language bindings it would be more idiomatic to
raise an exception, rather than just have the process terminate. If
libzmq returned a
On 12/02/2012, at 11:40 AM, Gary Wright wrote:
>
> On Feb 11, 2012, at 4:53 PM, Pieter Hintjens wrote:
>>
>> So in my libraries, like CZMQ, I validate input arguments with
>> asserts, systematically.
>
> And yet for some language bindings it would be more idiomatic to
> raise an exception, rat
39 matches
Mail list logo
