Hello,
I was trying to use ZMQ in a C++ program that also uses the STL to open
regular files and that uses the open(2) and ioctl(2) syscalls of the
Linux kernel for SPI communication (on an ARM platform). For certain
combinations of opening and closing a regular file and binding to a TCP
or Inproc
Am 20.01.2015 14:35, schrieb Olaf Mandel:
-Snipp-
>
>
> #include
> #include
-Snipp-
Shoot: That was missing a few include statements at the top the program
and the compile instructions. Correct start of the demo program:
/*
* Compile with:
* g++ -Wall -Werror -Wextra -o test test.cpp -lz
Do you see the same behavior if you replace C with fopen() ?
On Tue, Jan 20, 2015 at 7:40 AM, Olaf Mandel
wrote:
> Am 20.01.2015 14:35, schrieb Olaf Mandel:
> -Snipp-
> >
> >
> > #include
> > #include
> -Snipp-
>
> Shoot: That was missing a few include statements at the top the program
> and t
Hello Thomas,
thank you for the quick answer.
Am 20.01.2015 15:11, schrieb Thomas Rodgers:
> Do you see the same behavior if you replace C with fopen() ?
-Snipp-
Not quite: if the error occurs, the behaviour is the same as before. But
now the error _always_ happens: closing the file descriptor i
No, not really. libc++ doesn't do anything particularly interesting with
fd's but I just wanted to formally rule it out.
Unfortunately I don't have a system (or any experience dealing) with SPI
devices. I don't think libzmq does anything particularly 'funky' with any
of the file descriptors it mana
Hello,
I don't really see anything in the small example that could cause a bug.
I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi +
a Piface digital card (which is a SPI device), and I have no trouble.
My kernel version is 3.12.28+ and I use a recent (a few commits behind
HEAD)
Hello,
Am 20.01.2015 18:07, schrieb Arnaud Kapp:
> I don't really see anything in the small example that could cause a bug.
> I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi +
> a Piface digital card (which is a SPI device), and I have no trouble.
>
At least in the C++ versio
>
> At least in the C++ version, the problem is relatively fragile
I always see the problem in my pure-C test
There are those that maintain that C is a simpler and more robust language
than C++ :-)~
On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel
wrote:
> Hello,
>
> Am 20.01.2015 18:07, schri
Haha be careful Thomas or you will wake Pieter :)
Well I am mixing socket operations binds/connects with opening and
closing files (and reading and writing from/to files).
I also use ZMQ to poll on my files' descriptors. So at first sight it
doesn't look like a ZMQ bug.
I see two things to try:
Hello,
Am 20.01.2015 22:02, schrieb Arnaud Kapp:
-Snipp-
>> On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel
>> wrote:
-Snipp-
>>> Good point, my machine and version numbers are:
>>>
>>> CPU: Freescale i.MX537 (Cortex-A8, NEON)
>>> GCC: 4.8.1, cross-compiling
>>> Linux: 3.10.28 + many platform p
Are you sure that the ioctl call failed? You are printing out errno without
having checked the return code of the ioctl call.
Hello,
Am 20.01.2015 22:02, schrieb Arnaud Kapp:
-Snipp-
>> On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel
>> wrote:
-Snipp-
>>> Good point, my machine and version numbers
Hello,
Am 21.01.2015 22:31, schrieb KIU Shueng Chuan:
> Are you sure that the ioctl call failed? You are printing out errno without
> having checked the return code of the ioctl call.
-Snipp-
that actually was the problem!!! My own code had more debug checks to
verify that none of the previous ca
Hi,
It is a well known bug to be checking the errno value without first checking
that the system call failed. The errno number has no meaning _unless_ the system
call failed, it doesn't matter what it's value is if there hasn't been an error.
Hope that helps...
Ed
--
---
13 matches
Mail list logo