From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <505F1BE5.8010202@xenomai.org> Date: Sun, 23 Sep 2012 16:25:41 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <50483A49.5090100@ebus.com> <504C7797.8040201@xenomai.org> <5058F5F6.2060708@xenomai.org> <505F175C.2020702@xenomai.org> <505F17A1.5040302@xenomai.org> <505F1837.9030701@xenomai.org> <505F187E.7080308@xenomai.org> <505F1A1A.3090702@xenomai.org> <505F1ADE.9000105@xenomai.org> In-Reply-To: <505F1ADE.9000105@xenomai.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Queue corruption from XDDP in Xenomai 2.6.1 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Doug Brunner , xenomai@xenomai.org 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.