[zeromq-dev] Port of ZeroMQ to QNX 6.4

[Armin Steinhoff]

Hi Martin,

I have now tested the ipc:// communication.  It doesn't work in poll mode.
There is always an abort in poll.cpp:

# local_lat ipc:///tmp/sock 10 10000 &  ( the path must reference a flat 
file ...)
[1] 50253857
# Assertion failed: !(it->revents & POLLNVAL) (poll.cpp:170)

It works only with select(2).

Best Regards

--Armin


Martin Sustrik wrote:
> Hi Armin,
>
>   
>> OK ... the porting steps are:
>>
>> - CC=qcc CXX=QCC configure --with-c --with-perf   .... if only 
>> C-bindings are requested
>>
>> - then add to platform.hpp:
>>
>>                 #define rpl_malloc malloc
>>                 #define ZMQ_FORCE_SELECT 1
>>
>> That's all.
>>     
>
> You can dith the ZMQ_FORCE_SELECT part. I've asked you to add it in just 
> for debugging purposes. The macro forces 0MQ to poll using select(2). 
> The default for QNX is poll(2) which is much more efficient, so you 
> should leave it that way.
>   
OK ... I removed "#define ZMQ_FORCE_SELECT 1".
The result is a little bit confusing :)

The executables located in "perf/c" are now not working.
 "local_lat" e.g. terminates in the following way:

# local_lat tcp://192.168.178.129:5555 10 1000
Assertion failed: !(it->revents & POLLNVAL) (poll.cpp:170)
Abort (core dumped)
#

The executables in perf/c/.libs are working with the problem below!!
The performance isn't better as the select(2) based version ...

Regards

--Armin


> As for rpl_malloc, this is what I've found:
>
> http://sources.redhat.com/ml/automake/2003-05/msg00043.html
>
> Others may have suggestions about the issue.
>
>   
>> That's the backtrace for that problem:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb826042f in std::ios_base::~ios_base () from /usr/qnx640/target/qnx6/x86/lib/libcpp.so.4
>> (gdb) backtrace
>> #0  0xb826042f in std::ios_base::~ios_base () from /usr/qnx640/target/qnx6/x86/lib/libcpp.so.4
>> #1  0xb84051e6 in __tcf_3 () from /usr/qnx640/target/qnx6/x86/lib/libecpp.so.4
>> #2  0xb0329445 in __cxa_finalize () from /usr/qnx640/target/qnx6/x86/lib/libc.so.3
>> #3  0xb83fb624 in _btext () from /usr/qnx640/target/qnx6/x86/lib/libecpp.so.4
>> #4  0xb840c149 in _fini () from /usr/qnx640/target/qnx6/x86/lib/libecpp.so.4
>> #5  0xb033dae6 in fini () from /usr/qnx640/target/qnx6/x86/lib/libc.so.3
>> #6  0xb033dc48 in _do_exit_fini () from /usr/qnx640/target/qnx6/x86/lib/libc.so.3
>> #7  0xb03294e1 in _cleanup () from /usr/qnx640/target/qnx6/x86/lib/libc.so.3
>> #8  0xb0329bd7 in exit () from /usr/qnx640/target/qnx6/x86/lib/libc.so.3
>> #9  0x08048830 in _start ()
>> (gdb)         
>>     
>
> That's pretty strange. ios_base is not used anywhere in 0MQ, to be 
> precise, C++ streams are not used at all.
>
> The code seems to destroy a global instance of ios_base on exit. Maybe 
> there's an instance in C++ runtime? If so, there must still remain some 
> misinteraction between your libraries.
>
> Martin
> _______________________________________________
> 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/20100307/36f07788/attachment.htm>