Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart <frederik_bayart@yahoo.co.uk>]

Sorry for previous mail with no additional content, yahoo mail client is very sensitive apparently.

> On Saturday, 1 August 2015, 10:43, Philippe Gerum <rpm@xenomai.org> wrote:
>On 07/31/2015 07:54 PM, Frederik Bayart wrote:
>>> On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>>> On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>>>
>>>>> I found already that 'select' on  socket(PF_UNIX, SOCK_STREAM, 0)  causes Interrupted system call (errno 4).
>>>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>>>
>>>>
>>>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>>>
>>> libtrank is just an overlay on top of libalchemy, only consisting of
>>> fairly simple wrappers. I would suspect a difference in the flags passed
>>> to xeno-config instead.
>>
>> I succeeded to start my server using alchemy directly.
>>
>> Via trank the program generates a flood of error:
>>
>> $ sudo ./ptest
>>
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ptest.c:68 ERROR: select(4): Interrupted system call
>> ...
>>
>> In attachment a test file ptest.c and makefile to reproduce the problem.
>>
>> My original server uses both native and posix calls, for that I used both native and posix flags.
>>
>> XENO_CFLAGS = $(shell $(XENOCONFIG) --posix  --compat --native --cflags )
>> XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )
>>
>> With alchemy directly there is no problem :
>>
>> XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
>> XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)
>>
>>
>> I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :
>>
>> If I link with xeno-config  --posix --ldflags --compat, I get :
>>
>> cc -Wl,@/usr/lib/cobalt.wrappers -ltrank  /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt    -lfuse -pthread  -o ptest ptest.o
>> /usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
>> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
>> /usr/lib/libtrank.so: undefined reference to `rt_task_self'
>...
>> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
>> /usr/lib/libtrank.so: undefined reference to `xnmalloc'
>> collect2: error: ld returned 1 exit status
>> makefile:27: recipe for target 'ptest' failed
>> make: *** [ptest] Error 1
>>
>> With the --native flag added, this is solved because  -lalchemy -lcopperplate is then added.
>
>The issue is not between --alchemy and --native, but with --posix being
>added or not. I could not reproduce this behavior (x86, ppc or arm)
>using your exact test code (I can see timeouts triggering each 5s), but
>looking at it, I'm pretty sure this is due to passing regular linux fds
>(from socket(AF_UNIX) to RTDM services.
>
>When --posix is given, select(), socket() and friends will be routed to
>RTDM _first_, which will check whether the corresponding channels are
>connected to a real-time driver. If the fds are not managed by RTDM, the
>call will be redirected to the glibc eventually. I don't explain why
>your code receives EINTR from RTDM's select() yet, but this is most
>likely not related to libtrank. This behavior is unexpected though, so
>we have to find why Xenomai's select() behaves like this.

If I can help, let me know, then I try to make some time to look at it.
If you can't reproduce the problem, I could always run some test program on my PC.
What is the best way to debug it ?
Just to exclude : could it be an installation issue ?

Have you xenomai installed in /usr/xenomai/... ?
I'm using debian installation so that could be a difference. Any hardcoded library paths ?

Frederik

>
>In the meantime, if you want to mix Xenomai/POSIX calls with regular
>glibc ones when --posix is in effect, you can alternatively:
>
>- tag all regular POSIX calls for which a Xenomai counterpart exist with
>__STD(call(args))
>- invoke __real_call(args)
>
>Alternatively, you can drop --posix which will disable the POSIX
>wrapping for your code, then invoke __RT(call(args)) explicitly for
>Xenomai real-time services.
>
>Philippe.