Re: [zeromq-dev] Open file leak during DNS resolution while network is down (regression in libzmq-4.1.0 and libzmq-master) #1302

2015-01-20 Thread Pieter Hintjens
OK, thanks for the simple test case. I'm not familiar enough with the internals of libzmq to debug this. I see that tcp_connecter.cpp is closing the socket if it can't resolve the hostname. However it's possible some error handling isn't right here. On Tue, Jan 20, 2015 at 5:04 AM, Tomas Krajca

[zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Olaf Mandel
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

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Olaf Mandel
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

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Thomas Rodgers
Do you see the same behavior if you replace C with fopen() ? On Tue, Jan 20, 2015 at 7:40 AM, Olaf Mandel o.man...@menlosystems.com wrote: Am 20.01.2015 14:35, schrieb Olaf Mandel: -Snipp- #include sys/ioctl.h #include zmq.hpp -Snipp- Shoot: That was missing a few include statements

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Olaf Mandel
Am 20.01.2015 14:35, schrieb Olaf Mandel: -Snipp- #include sys/ioctl.h #include zmq.hpp -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

Re: [zeromq-dev] Open file leak during DNS resolution while network is down (regression in libzmq-4.1.0 and libzmq-master) #1302

2015-01-20 Thread Thomas Rodgers
I'm running your sample against current libzmq trunk, Ubuntu 14.04 and I am unable to reproduce any leak. On Tue, Jan 20, 2015 at 2:08 AM, Pieter Hintjens p...@imatix.com wrote: OK, thanks for the simple test case. I'm not familiar enough with the internals of libzmq to debug this. I see

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Arnaud Kapp
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

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Olaf Mandel
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++ version,

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Thomas Rodgers
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

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Thomas Rodgers
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 o.man...@menlosystems.com wrote: Hello, Am

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

2015-01-20 Thread Arnaud Kapp
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: