[Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Doug Brunner]

It looks like the bug I wrote about back in June still exists in Xenomai 
2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens 
an XDDP socket, then a Linux thread opens its end of the pipe, then the 
RT thread stops, then with the Linux thread still holding its end of the 
pipe another RT thread tries to open an XDDP socket with the same minor 
number). With Xenomai queue and I-pipe debugging enabled, I got a report 
of a corrupted queue. I've attached my config, test case, and serial 
console log.

So far I haven't found anything in the XDDP or underlying xnpipe_* code 
that would suggest why this is happening. However something is 
definitely going wrong, since xnpipe_minor_free should not be called 
until my Linux task closes its end of the pipe, so the call by the 
second RT thread to open the pipe should fail with -EBUSY. Any thoughts 
on why this might be happening?

-- 
     Doug Brunner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-3.2.21-ipipe-small-2-ipd.gz
Type: application/x-gzip
Size: 13798 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120905/caa35f02/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xddp-trycrash.c
Type: text/x-csrc
Size: 6234 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120905/caa35f02/attachment.c>
-------------- next part --------------
Loading Linux 3.2.21-ipipe-small-2-ipd ...

?EXT4-fs (hda1): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (hda1): couldn't mount as ext2 due to feature incompatibilities

INIT: version 2.88 booting

Using makefile-style concurrent boot in runlevel S.
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Setting preliminary keymap...done.
Activating swap...done.
Checking root file system...fsck from util-linux-ng 2.17.2
/dev/hda1: clean, 72970/256512 files, 579050/1026048 blocks
done.
Cleaning up ifupdown....
Setting up networking....
Loading kernel modules...done.
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.17.2
done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Configuring network interfaces...done.
Starting portmap daemon....
Starting NFS common utilities: statd.
Cleaning up temporary files....
Setting console screen modes.
^[]Rcannot (un)set powersave mode
^[[9;30]^[[14;30]Skipping font and keymap setup (handled by console-setup).
Setting up console font and keymap...done.
Setting sensors limits.
Setting kernel variables ...done.
Loading the saved-state of the serial devices... 
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A

INIT: Entering runlevel: 2

Using makefile-style concurrent boot in runlevel 2.
Enabling additional executable binary formats: binfmt-supportmount: mount point /proc/sys/fs/binfmt_misc does not exist
Starting NFS common utilities: statd.
Starting portmap daemon...Already running..
Starting enhanced syslogd: rsyslogd.
Starting anac(h)ronistic cron: anacron.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
Starting system message bus: dbus.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Starting MTA:Starting kerneloops:
 exim4.
Loading cpufreq kernel modules...done (none).
CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, governor not available...done.
Starting network connection manager: NetworkManager.
Starting OpenBSD Secure Shell server: sshd.
I-pipe: Detected stalled head domain, probably caused by a bug.
        A critical section may have been left unterminated.

Debian GNU/Linux 6.0 eve-0000 ttyS0

eve-0000 login: root
Password: 
Last login: Wed Sep  5 10:53:59 PDT 2012 on ttyS0
Linux eve-0000 3.2.21-ipipe-small-2-ipd #7 Wed Sep 5 17:45:26 UTC 2012 i586

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@eve-0000:~# ./xddp-trycrash
Xenomai: corrupted queue, qslot->elems=5/5, qslot=b065b9c0 at kernel/xenomai/nucleus/heap.c:332

 CPU  PID    PRI      TIMEOUT  STAT      NAME
>  0  0       -1      0        00500080  ROOT
   0  1539     0      0        00b00380  xddp-trycrash
   0  1542     0      0        00b00380  xddp-trycrash
   0  1543    42      0        00300380  xddp-trycrash
Master time base: clock=100421966997

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/06/2012 07:53 AM, Doug Brunner wrote:
> It looks like the bug I wrote about back in June still exists in Xenomai
> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
> an XDDP socket, then a Linux thread opens its end of the pipe, then the
> RT thread stops, then with the Linux thread still holding its end of the
> pipe another RT thread tries to open an XDDP socket with the same minor
> number). With Xenomai queue and I-pipe debugging enabled, I got a report
> of a corrupted queue. I've attached my config, test case, and serial
> console log.
> 
> So far I haven't found anything in the XDDP or underlying xnpipe_* code
> that would suggest why this is happening. However something is
> definitely going wrong, since xnpipe_minor_free should not be called
> until my Linux task closes its end of the pipe, so the call by the
> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
> on why this might be happening?
> 

Yes, please have a look at the commit log there:
http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca

This patch should fix the issue raised by the test case you sent
(actually, it does, it was very useful to spot the problem - thanks for
this).

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Doug Brunner]

On 09/09/2012 04:03 AM, Philippe Gerum wrote:
> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>> It looks like the bug I wrote about back in June still exists in Xenomai
>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>> RT thread stops, then with the Linux thread still holding its end of the
>> pipe another RT thread tries to open an XDDP socket with the same minor
>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>> of a corrupted queue. I've attached my config, test case, and serial
>> console log.
>>
>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>> that would suggest why this is happening. However something is
>> definitely going wrong, since xnpipe_minor_free should not be called
>> until my Linux task closes its end of the pipe, so the call by the
>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>> on why this might be happening?
>>
> Yes, please have a look at the commit log there:
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>
> This patch should fix the issue raised by the test case you sent
> (actually, it does, it was very useful to spot the problem - thanks for
> this).
Thanks Philippe--I will patch this in and try it on my test hardware 
tomorrow. (Unfortunately my KVM virtual machine will not boot any 3.2 
kernel with I-pipe AFAICT; around the time it remounts the root FS 
read-write it begins waiting for something that never happens :( )

     --Doug Brunner

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Doug Brunner]

On 09/09/2012 05:19 PM, Doug Brunner wrote:
> On 09/09/2012 04:03 AM, Philippe Gerum wrote:
>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>> It looks like the bug I wrote about back in June still exists in 
>>> Xenomai
>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>> RT thread stops, then with the Linux thread still holding its end of 
>>> the
>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>> number). With Xenomai queue and I-pipe debugging enabled, I got a 
>>> report
>>> of a corrupted queue. I've attached my config, test case, and serial
>>> console log.
>>>
>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>> that would suggest why this is happening. However something is
>>> definitely going wrong, since xnpipe_minor_free should not be called
>>> until my Linux task closes its end of the pipe, so the call by the
>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>> on why this might be happening?
>>>
>> Yes, please have a look at the commit log there:
>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca 
>>
>>
>> This patch should fix the issue raised by the test case you sent
>> (actually, it does, it was very useful to spot the problem - thanks for
>> this).
> Thanks Philippe--I will patch this in and try it on my test hardware 
> tomorrow. (Unfortunately my KVM virtual machine will not boot any 3.2 
> kernel with I-pipe AFAICT; around the time it remounts the root FS 
> read-write it begins waiting for something that never happens :( )
>
>     --Doug Brunner
Works fine (passes regression test and appears to run my application 
OK), thanks again.

I don't suppose anyone has a suggestion for what I might do to debug the 
hang during boot in KVM? :)

     --Doug Brunner

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Gilles Chanteperdrix]

On 09/11/2012 06:12 AM, Doug Brunner wrote:

> On 09/09/2012 05:19 PM, Doug Brunner wrote:
>> On 09/09/2012 04:03 AM, Philippe Gerum wrote:
>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>> It looks like the bug I wrote about back in June still exists in 
>>>> Xenomai
>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>> RT thread stops, then with the Linux thread still holding its end of 
>>>> the
>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a 
>>>> report
>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>> console log.
>>>>
>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>> that would suggest why this is happening. However something is
>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>> until my Linux task closes its end of the pipe, so the call by the
>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>> on why this might be happening?
>>>>
>>> Yes, please have a look at the commit log there:
>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca 
>>>
>>>
>>> This patch should fix the issue raised by the test case you sent
>>> (actually, it does, it was very useful to spot the problem - thanks for
>>> this).
>> Thanks Philippe--I will patch this in and try it on my test hardware 
>> tomorrow. (Unfortunately my KVM virtual machine will not boot any 3.2 
>> kernel with I-pipe AFAICT; around the time it remounts the root FS 
>> read-write it begins waiting for something that never happens :( )
>>
>>     --Doug Brunner
> Works fine (passes regression test and appears to run my application 
> OK), thanks again.
> 
> I don't suppose anyone has a suggestion for what I might do to debug the 
> hang during boot in KVM? :)


It is likely a timer issue, you have to put some printk around to see if
the timer interrupt is still ticking for xenomai and for linux, and if
it is not ticking try and understand why.

-- 
                                                                Gilles.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Gilles Chanteperdrix]

On 09/09/2012 01:03 PM, Philippe Gerum wrote:

> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>> It looks like the bug I wrote about back in June still exists in Xenomai
>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>> RT thread stops, then with the Linux thread still holding its end of the
>> pipe another RT thread tries to open an XDDP socket with the same minor
>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>> of a corrupted queue. I've attached my config, test case, and serial
>> console log.
>>
>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>> that would suggest why this is happening. However something is
>> definitely going wrong, since xnpipe_minor_free should not be called
>> until my Linux task closes its end of the pipe, so the call by the
>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>> on why this might be happening?
>>
> 
> Yes, please have a look at the commit log there:
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
> 
> This patch should fix the issue raised by the test case you sent
> (actually, it does, it was very useful to spot the problem - thanks for
> this).


Hi Philippe, 

I am using a test case which should be about the same as Doug's, however when running the test
case twice, the second test fails at bind with EADDRINUSE.

The testcase (as a patch to be compiled as part of the regression suite):

diff --git a/src/testsuite/regression/posix/Makefile.am b/src/testsuite/regression/posix/Makefile.am
index 2107482..bd3c1cf 100644
--- a/src/testsuite/regression/posix/Makefile.am
+++ b/src/testsuite/regression/posix/Makefile.am
@@ -4,7 +4,7 @@ noinst_HEADERS = check.h
 
 CCLD = $(top_srcdir)/scripts/wrap-link.sh $(CC)
 
-tst_PROGRAMS = leaks shm mprotect nano_test
+tst_PROGRAMS = leaks shm mprotect nano_test xddp_test
 
 CPPFLAGS = $(XENO_USER_CFLAGS) \
 	-I$(top_srcdir)/include/posix \
diff --git a/src/testsuite/regression/posix/Makefile.in b/src/testsuite/regression/posix/Makefile.in
index 9f77e38..da24e2f 100644
--- a/src/testsuite/regression/posix/Makefile.in
+++ b/src/testsuite/regression/posix/Makefile.in
@@ -37,7 +37,7 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 tst_PROGRAMS = leaks$(EXEEXT) shm$(EXEEXT) mprotect$(EXEEXT) \
-	nano_test$(EXEEXT)
+	nano_test$(EXEEXT) xddp_test$(EXEEXT)
 subdir = src/testsuite/regression/posix
 DIST_COMMON = $(noinst_HEADERS) $(srcdir)/Makefile.am \
 	$(srcdir)/Makefile.in
@@ -78,6 +78,11 @@ shm_OBJECTS = shm.$(OBJEXT)
 shm_LDADD = $(LDADD)
 shm_DEPENDENCIES = ../../../skins/posix/libpthread_rt.la \
 	../../../skins/common/libxenomai.la
+xddp_test_SOURCES = xddp_test.c
+xddp_test_OBJECTS = xddp_test.$(OBJEXT)
+xddp_test_LDADD = $(LDADD)
+xddp_test_DEPENDENCIES = ../../../skins/posix/libpthread_rt.la \
+	../../../skins/common/libxenomai.la
 DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)/src/include
 depcomp = $(SHELL) $(top_srcdir)/config/depcomp
 am__depfiles_maybe = depfiles
@@ -90,8 +95,8 @@ LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
 LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
 	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
 	$(LDFLAGS) -o $@
-SOURCES = leaks.c mprotect.c nano_test.c shm.c
-DIST_SOURCES = leaks.c mprotect.c nano_test.c shm.c
+SOURCES = leaks.c mprotect.c nano_test.c shm.c xddp_test.c
+DIST_SOURCES = leaks.c mprotect.c nano_test.c shm.c xddp_test.c
 HEADERS = $(noinst_HEADERS)
 ETAGS = etags
 CTAGS = ctags
@@ -358,6 +363,9 @@ nano_test$(EXEEXT): $(nano_test_OBJECTS) $(nano_test_DEPENDENCIES)
 shm$(EXEEXT): $(shm_OBJECTS) $(shm_DEPENDENCIES) 
 	@rm -f shm$(EXEEXT)
 	$(LINK) $(shm_OBJECTS) $(shm_LDADD) $(LIBS)
+xddp_test$(EXEEXT): $(xddp_test_OBJECTS) $(xddp_test_DEPENDENCIES) 
+	@rm -f xddp_test$(EXEEXT)
+	$(LINK) $(xddp_test_OBJECTS) $(xddp_test_LDADD) $(LIBS)
 
 mostlyclean-compile:
 	-rm -f *.$(OBJEXT)
@@ -369,6 +377,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mprotect.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/nano_test.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/shm.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/xddp_test.Po@am__quote@
 
 .c.o:
 @am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
diff --git a/src/testsuite/regression/posix/check.h b/src/testsuite/regression/posix/check.h
index 63dc4a3..5530e8a 100644
--- a/src/testsuite/regression/posix/check.h
+++ b/src/testsuite/regression/posix/check.h
@@ -10,7 +10,7 @@
 	({                                                              \
 		int rc = (expr);                                        \
 		if (rc > 0) {                                           \
-			fprintf(stderr, "FAILURE %s:%d: "#expr ": %s\n", __FILE__, __LINE__, strerror(rc)); \
+			fprintf(stderr, "FAILURE %s:%d: %s: %s\n", __FILE__, __LINE__, #expr, strerror(rc)); \
 			exit(EXIT_FAILURE);				\
 		}                                                       \
 		rc;                                                     \
@@ -20,7 +20,7 @@
 	({                                                              \
 		int rc = (expr);                                        \
 		if (rc < 0) {                                           \
-			fprintf(stderr, "FAILURE %s:%d: "#expr ": %s\n", __FILE__, __LINE__, strerror(errno)); \
+			fprintf(stderr, "FAILURE %s:%d: %s: %s\n", __FILE__, __LINE__, #expr, strerror(errno)); \
 			exit(EXIT_FAILURE);				\
 		}                                                       \
 		rc;                                                     \
@@ -30,7 +30,7 @@
 	({                                                              \
 		void *rc = (expr);					\
 		if (rc == MAP_FAILED) {					\
-			fprintf(stderr, "FAILURE %s:%d: "#expr ": %s\n", __FILE__, __LINE__, strerror(errno)); \
+			fprintf(stderr, "FAILURE %s:%d: %s: %s\n", __FILE__, __LINE__, #expr, strerror(errno)); \
 			exit(EXIT_FAILURE);				\
 		}                                                       \
 		rc;                                                     \
diff --git a/src/testsuite/regression/posix/xddp_test.c b/src/testsuite/regression/posix/xddp_test.c
new file mode 100644
index 0000000..1c9389f
--- /dev/null
+++ b/src/testsuite/regression/posix/xddp_test.c
@@ -0,0 +1,156 @@
+/*
+ * XDDP-based RT/NRT threads regression test.
+ *
+ * Original author: Doug Brunner
+ *
+ * This test causes a crash with Xenomai 2.6.1 and earlier versions.
+ */
+#include <sys/mman.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <string.h>
+#include <malloc.h>
+#include <pthread.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <rtdk.h>
+#include <rtdm/rtipc.h>
+#include "check.h"
+
+pthread_t rt, nrt;
+
+#define XDDP_PORT 0	/* [0..CONFIG-XENO_OPT_PIPE_NRDEV - 1] */
+
+void *realtime_thread(void *arg)
+{
+	unsigned long count = (unsigned long)arg;
+	struct sockaddr_ipc saddr;
+	struct timespec ts;
+	size_t poolsz;
+	int ret, s;
+
+	/*
+	 * Get a datagram socket to bind to the RT endpoint. Each
+	 * endpoint is represented by a port number within the XDDP
+	 * protocol namespace.
+	 */
+	s = check_unix(socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP));
+
+	/*
+	 * Set a local 16k pool for the RT endpoint. Memory needed to
+	 * convey datagrams will be pulled from this pool, instead of
+	 * Xenomai's system pool.
+	 */
+	poolsz = 16384; /* bytes */
+	ret = check_unix(setsockopt(s, SOL_XDDP, XDDP_POOLSZ,
+				    &poolsz, sizeof(poolsz)));
+
+	/*
+	 * Bind the socket to the port, to setup a proxy to channel
+	 * traffic to/from the Linux domain.
+	 *
+	 * saddr.sipc_port specifies the port number to use.
+	 */
+	memset(&saddr, 0, sizeof(saddr));
+	saddr.sipc_family = AF_RTIPC;
+	saddr.sipc_port = XDDP_PORT;
+	ret = bind(s, (struct sockaddr *)&saddr, sizeof(saddr));
+	if (ret == 0 && errno == EADDRINUSE && count == 1) {
+		fprintf(stderr, "Success.\n");
+		exit(EXIT_SUCCESS);
+	} else if (ret < 0) {
+		fprintf(stderr, "bind: %m\n");
+		exit(EXIT_FAILURE);
+	}
+
+	ts.tv_sec = 0;
+	ts.tv_nsec = 500000000; /* 500 ms */
+	check_unix(clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL));
+
+	check_unix(close(s));
+
+	return NULL;
+}
+
+void *regular_thread(void *arg)
+{
+	char buf[128], *devname;
+	int fd, ret;
+
+	check_unix(asprintf(&devname, "/dev/rtp%d", XDDP_PORT));
+
+	fd = check_unix(open(devname, O_RDWR));
+	free(devname);
+
+	for (;;) {
+		/* Get the next message from realtime_thread. */
+		ret = read(fd, buf, sizeof(buf));
+
+		usleep(10000);
+	}
+
+	return NULL;
+}
+
+void cleanup_upon_sig(int sig)
+{
+	pthread_cancel(rt);
+	pthread_cancel(nrt);
+	signal(sig, SIG_DFL);
+	pthread_join(rt, NULL);
+	pthread_join(nrt, NULL);
+	raise(sig);
+}
+
+int main(int argc, char **argv)
+{
+	struct sched_param rtparam = { .sched_priority = 42 };
+	pthread_attr_t rtattr, regattr;
+	sigset_t mask, oldmask;
+
+	mlockall(MCL_CURRENT | MCL_FUTURE);
+
+	sigemptyset(&mask);
+	sigaddset(&mask, SIGINT);
+	signal(SIGINT, cleanup_upon_sig);
+	sigaddset(&mask, SIGTERM);
+	signal(SIGTERM, cleanup_upon_sig);
+	sigaddset(&mask, SIGHUP);
+	signal(SIGHUP, cleanup_upon_sig);
+	pthread_sigmask(SIG_BLOCK, &mask, &oldmask);
+
+	pthread_attr_init(&rtattr);
+	pthread_attr_setdetachstate(&rtattr, PTHREAD_CREATE_JOINABLE);
+	pthread_attr_setinheritsched(&rtattr, PTHREAD_EXPLICIT_SCHED);
+	pthread_attr_setschedpolicy(&rtattr, SCHED_FIFO);
+	pthread_attr_setschedparam(&rtattr, &rtparam);
+
+	check_pthread(pthread_create(&rt, &rtattr, &realtime_thread, NULL));
+	pthread_attr_destroy(&rtattr);
+
+	pthread_attr_init(&regattr);
+	pthread_attr_setdetachstate(&regattr, PTHREAD_CREATE_JOINABLE);
+	pthread_attr_setinheritsched(&regattr, PTHREAD_EXPLICIT_SCHED);
+	pthread_attr_setschedpolicy(&regattr, SCHED_OTHER);
+
+	check_pthread(pthread_create(&nrt, &regattr, &regular_thread, NULL));
+	pthread_attr_destroy(&regattr);
+
+	sleep(1);	// after this call returns the RT thread will have ended
+
+	pthread_attr_init(&rtattr);	// start another RT thread to cause the crash
+	pthread_attr_setdetachstate(&rtattr, PTHREAD_CREATE_JOINABLE);
+	pthread_attr_setinheritsched(&rtattr, PTHREAD_EXPLICIT_SCHED);
+	pthread_attr_setschedpolicy(&rtattr, SCHED_FIFO);
+	pthread_attr_setschedparam(&rtattr, &rtparam);
+
+	check_pthread(pthread_create(&rt, &rtattr,
+&realtime_thread, (void *)1UL));
+	pthread_attr_destroy(&rtattr);
+
+	sigsuspend(&oldmask);
+
+	return 0;
+}


-- 
                                                                Gilles.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
> 
>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>> RT thread stops, then with the Linux thread still holding its end of the
>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>> of a corrupted queue. I've attached my config, test case, and serial
>>> console log.
>>>
>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>> that would suggest why this is happening. However something is
>>> definitely going wrong, since xnpipe_minor_free should not be called
>>> until my Linux task closes its end of the pipe, so the call by the
>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>> on why this might be happening?
>>>
>>
>> Yes, please have a look at the commit log there:
>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>
>> This patch should fix the issue raised by the test case you sent
>> (actually, it does, it was very useful to spot the problem - thanks for
>> this).
> 
> 
> Hi Philippe, 
> 
> I am using a test case which should be about the same as Doug's, however when running the test
> case twice, the second test fails at bind with EADDRINUSE.

This is intended, the port remains bound until both ends
have released it, e.g.:

diff --git a/src/testsuite/regression/posix/xddp_test.c b/src/testsuite/regression/posix/xddp_test.c
index 1c9389f..c75f8c1 100644
--- a/src/testsuite/regression/posix/xddp_test.c
+++ b/src/testsuite/regression/posix/xddp_test.c
@@ -79,6 +79,7 @@ void *regular_thread(void *arg)
 	char buf[128], *devname;
 	int fd, ret;
 
+reset:
 	check_unix(asprintf(&devname, "/dev/rtp%d", XDDP_PORT));
 
 	fd = check_unix(open(devname, O_RDWR));
@@ -87,7 +88,11 @@ void *regular_thread(void *arg)
 	for (;;) {
 		/* Get the next message from realtime_thread. */
 		ret = read(fd, buf, sizeof(buf));
-
+		if (ret < 0) {
+			fprintf(stderr, "read: %m\n");
+			close(fd);
+			goto reset;
+		}
 		usleep(10000);
 	}

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Gilles Chanteperdrix]

On 09/23/2012 04:06 PM, Philippe Gerum wrote:

> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>
>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>> console log.
>>>>
>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>> that would suggest why this is happening. However something is
>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>> until my Linux task closes its end of the pipe, so the call by the
>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>> on why this might be happening?
>>>>
>>>
>>> Yes, please have a look at the commit log there:
>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>
>>> This patch should fix the issue raised by the test case you sent
>>> (actually, it does, it was very useful to spot the problem - thanks for
>>> this).
>>
>>
>> Hi Philippe, 
>>
>> I am using a test case which should be about the same as Doug's, however when running the test
>> case twice, the second test fails at bind with EADDRINUSE.
> 
> This is intended, the port remains bound until both ends
> have released it, e.g.:


Well, should not the port be released when the process finishes?

-- 
                                                                Gilles.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
> 
>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>
>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>> console log.
>>>>>
>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>> that would suggest why this is happening. However something is
>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>> on why this might be happening?
>>>>>
>>>>
>>>> Yes, please have a look at the commit log there:
>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>
>>>> This patch should fix the issue raised by the test case you sent
>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>> this).
>>>
>>>
>>> Hi Philippe, 
>>>
>>> I am using a test case which should be about the same as Doug's, however when running the test
>>> case twice, the second test fails at bind with EADDRINUSE.
>>
>> This is intended, the port remains bound until both ends
>> have released it, e.g.:
> 
> 
> Well, should not the port be released when the process finishes?
> 

You have two threads involved, there is no finishing process in your test.

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Gilles Chanteperdrix]

On 09/23/2012 04:09 PM, Philippe Gerum wrote:

> On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
>> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
>>
>>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>>
>>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>>> console log.
>>>>>>
>>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>>> that would suggest why this is happening. However something is
>>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>>> on why this might be happening?
>>>>>>
>>>>>
>>>>> Yes, please have a look at the commit log there:
>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>>
>>>>> This patch should fix the issue raised by the test case you sent
>>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>>> this).
>>>>
>>>>
>>>> Hi Philippe, 
>>>>
>>>> I am using a test case which should be about the same as Doug's, however when running the test
>>>> case twice, the second test fails at bind with EADDRINUSE.
>>>
>>> This is intended, the port remains bound until both ends
>>> have released it, e.g.:
>>
>>
>> Well, should not the port be released when the process finishes?
>>
> 
> You have two threads involved, there is no finishing process in your test.
> 


When I launch the test, it terminates saying "test passed", the two
threads dead. Then I launch the test again, and get an error EADDRINUSE
at bind.

-- 
                                                                Gilles.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/23/2012 04:11 PM, Gilles Chanteperdrix wrote:
> On 09/23/2012 04:09 PM, Philippe Gerum wrote:
> 
>> On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
>>> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
>>>
>>>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>>>
>>>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>>>> console log.
>>>>>>>
>>>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>>>> that would suggest why this is happening. However something is
>>>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>>>> on why this might be happening?
>>>>>>>
>>>>>>
>>>>>> Yes, please have a look at the commit log there:
>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>>>
>>>>>> This patch should fix the issue raised by the test case you sent
>>>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>>>> this).
>>>>>
>>>>>
>>>>> Hi Philippe, 
>>>>>
>>>>> I am using a test case which should be about the same as Doug's, however when running the test
>>>>> case twice, the second test fails at bind with EADDRINUSE.
>>>>
>>>> This is intended, the port remains bound until both ends
>>>> have released it, e.g.:
>>>
>>>
>>> Well, should not the port be released when the process finishes?
>>>
>>
>> You have two threads involved, there is no finishing process in your test.
>>
> 
> 
> When I launch the test, it terminates saying "test passed", the two
> threads dead. Then I launch the test again, and get an error EADDRINUSE
> at bind.
> 

Not here, it just waits on sigsuspend, looping in the non-rt thread.
Closing the rtdm fildes manually via /proc/xenomai/rtdm would probably
"fix" the issue on your side.

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/23/2012 04:18 PM, Philippe Gerum wrote:
> On 09/23/2012 04:11 PM, Gilles Chanteperdrix wrote:
>> On 09/23/2012 04:09 PM, Philippe Gerum wrote:
>>
>>> On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
>>>> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
>>>>
>>>>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>>>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>>>>
>>>>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>>>>> console log.
>>>>>>>>
>>>>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>>>>> that would suggest why this is happening. However something is
>>>>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>>>>> on why this might be happening?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, please have a look at the commit log there:
>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>>>>
>>>>>>> This patch should fix the issue raised by the test case you sent
>>>>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>>>>> this).
>>>>>>
>>>>>>
>>>>>> Hi Philippe, 
>>>>>>
>>>>>> I am using a test case which should be about the same as Doug's, however when running the test
>>>>>> case twice, the second test fails at bind with EADDRINUSE.
>>>>>
>>>>> This is intended, the port remains bound until both ends
>>>>> have released it, e.g.:
>>>>
>>>>
>>>> Well, should not the port be released when the process finishes?
>>>>
>>>
>>> You have two threads involved, there is no finishing process in your test.
>>>
>>
>>
>> When I launch the test, it terminates saying "test passed", the two
>> threads dead. Then I launch the test again, and get an error EADDRINUSE
>> at bind.
>>
> 
> Not here, it just waits on sigsuspend, looping in the non-rt thread.
> Closing the rtdm fildes manually via /proc/xenomai/rtdm would probably
> "fix" the issue on your side.
> 

?
	if (ret == 0 && errno == EADDRINUSE && count == 1) {

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Philippe Gerum]

On 09/23/2012 04:21 PM, Philippe Gerum wrote:
> On 09/23/2012 04:18 PM, Philippe Gerum wrote:
>> On 09/23/2012 04:11 PM, Gilles Chanteperdrix wrote:
>>> On 09/23/2012 04:09 PM, Philippe Gerum wrote:
>>>
>>>> On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
>>>>> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
>>>>>
>>>>>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>>>>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>>>>>
>>>>>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>>>>>> console log.
>>>>>>>>>
>>>>>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>>>>>> that would suggest why this is happening. However something is
>>>>>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>>>>>> on why this might be happening?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, please have a look at the commit log there:
>>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>>>>>
>>>>>>>> This patch should fix the issue raised by the test case you sent
>>>>>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>>>>>> this).
>>>>>>>
>>>>>>>
>>>>>>> Hi Philippe, 
>>>>>>>
>>>>>>> I am using a test case which should be about the same as Doug's, however when running the test
>>>>>>> case twice, the second test fails at bind with EADDRINUSE.
>>>>>>
>>>>>> This is intended, the port remains bound until both ends
>>>>>> have released it, e.g.:
>>>>>
>>>>>
>>>>> Well, should not the port be released when the process finishes?
>>>>>
>>>>
>>>> You have two threads involved, there is no finishing process in your test.
>>>>
>>>
>>>
>>> When I launch the test, it terminates saying "test passed", the two
>>> threads dead. Then I launch the test again, and get an error EADDRINUSE
>>> at bind.
>>>
>>
>> Not here, it just waits on sigsuspend, looping in the non-rt thread.
>> Closing the rtdm fildes manually via /proc/xenomai/rtdm would probably
>> "fix" the issue on your side.
>>
> 
> ?
> 	if (ret == 0 && errno == EADDRINUSE && count == 1) {
> 

The test works as expected for me, with this fix:

diff --git a/src/testsuite/regression/posix/xddp_test.c b/src/testsuite/regression/posix/xddp_test.c
index 1c9389f..e2ef452 100644
--- a/src/testsuite/regression/posix/xddp_test.c
+++ b/src/testsuite/regression/posix/xddp_test.c
@@ -57,7 +57,7 @@ void *realtime_thread(void *arg)
 	saddr.sipc_family = AF_RTIPC;
 	saddr.sipc_port = XDDP_PORT;
 	ret = bind(s, (struct sockaddr *)&saddr, sizeof(saddr));
-	if (ret == 0 && errno == EADDRINUSE && count == 1) {
+	if (ret < 0 && errno == EADDRINUSE && count == 1) {
 		fprintf(stderr, "Success.\n");
 		exit(EXIT_SUCCESS);
 	} else if (ret < 0) {

-- 
Philippe.

Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1

[Gilles Chanteperdrix]

On 09/23/2012 04:25 PM, Philippe Gerum wrote:

> On 09/23/2012 04:21 PM, Philippe Gerum wrote:
>> On 09/23/2012 04:18 PM, Philippe Gerum wrote:
>>> On 09/23/2012 04:11 PM, Gilles Chanteperdrix wrote:
>>>> On 09/23/2012 04:09 PM, Philippe Gerum wrote:
>>>>
>>>>> On 09/23/2012 04:07 PM, Gilles Chanteperdrix wrote:
>>>>>> On 09/23/2012 04:06 PM, Philippe Gerum wrote:
>>>>>>
>>>>>>> On 09/19/2012 12:30 AM, Gilles Chanteperdrix wrote:
>>>>>>>> On 09/09/2012 01:03 PM, Philippe Gerum wrote:
>>>>>>>>
>>>>>>>>> On 09/06/2012 07:53 AM, Doug Brunner wrote:
>>>>>>>>>> It looks like the bug I wrote about back in June still exists in Xenomai
>>>>>>>>>> 2.6.1 (with Linux 3.2.21). I ran the same test case (an RT thread opens
>>>>>>>>>> an XDDP socket, then a Linux thread opens its end of the pipe, then the
>>>>>>>>>> RT thread stops, then with the Linux thread still holding its end of the
>>>>>>>>>> pipe another RT thread tries to open an XDDP socket with the same minor
>>>>>>>>>> number). With Xenomai queue and I-pipe debugging enabled, I got a report
>>>>>>>>>> of a corrupted queue. I've attached my config, test case, and serial
>>>>>>>>>> console log.
>>>>>>>>>>
>>>>>>>>>> So far I haven't found anything in the XDDP or underlying xnpipe_* code
>>>>>>>>>> that would suggest why this is happening. However something is
>>>>>>>>>> definitely going wrong, since xnpipe_minor_free should not be called
>>>>>>>>>> until my Linux task closes its end of the pipe, so the call by the
>>>>>>>>>> second RT thread to open the pipe should fail with -EBUSY. Any thoughts
>>>>>>>>>> on why this might be happening?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, please have a look at the commit log there:
>>>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=283c5f6eae1d1d7c65073e2f30fd40abdcf2c1ca
>>>>>>>>>
>>>>>>>>> This patch should fix the issue raised by the test case you sent
>>>>>>>>> (actually, it does, it was very useful to spot the problem - thanks for
>>>>>>>>> this).
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Philippe, 
>>>>>>>>
>>>>>>>> I am using a test case which should be about the same as Doug's, however when running the test
>>>>>>>> case twice, the second test fails at bind with EADDRINUSE.
>>>>>>>
>>>>>>> This is intended, the port remains bound until both ends
>>>>>>> have released it, e.g.:
>>>>>>
>>>>>>
>>>>>> Well, should not the port be released when the process finishes?
>>>>>>
>>>>>
>>>>> You have two threads involved, there is no finishing process in your test.
>>>>>
>>>>
>>>>
>>>> When I launch the test, it terminates saying "test passed", the two
>>>> threads dead. Then I launch the test again, and get an error EADDRINUSE
>>>> at bind.
>>>>
>>>
>>> Not here, it just waits on sigsuspend, looping in the non-rt thread.
>>> Closing the rtdm fildes manually via /proc/xenomai/rtdm would probably
>>> "fix" the issue on your side.
>>>
>>
>> ?
>> 	if (ret == 0 && errno == EADDRINUSE && count == 1) {
>>
> 
> The test works as expected for me, with this fix:


Indeed, sorry for the noise.

-- 
                                                                Gilles.