* rt_pipe_read(): timeout does not expire
@ 2021-09-25 16:20 Mauro S.
2021-10-05 16:00 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Mauro S. @ 2021-09-25 16:20 UTC (permalink / raw)
To: xenomai
Hi all,
I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
Please consider the attached simple test code.
When I start the application, I never see the "Pipe task running" printf.
When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
Analyzing the code with gdb, the timeout in tv structure inside
rt_pipe_read_timed() is the following
(gdb) thread 13
[Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
#0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
250 rtdm.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
#1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
from=from@entry=0x0,
fromlen=fromlen@entry=0x0) at rtdm.c:343
#2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
at pipe.c:423
#3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
buf=0x7ffff7188d60, size=4, timeout=500000)
at
/opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
#4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
#5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
#6 task_entry (arg=0x7ffff732ddc8) at task.c:219
#7 0x00007ffff7faaca9 in thread_trampoline
(arg=arg@entry=0x7fffffffe9c0) at internal.c:251
#8 0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
thread.c:123
#9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
pthread_create.c:477
#10 0x00007ffff7e7edcf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) frame 2
#2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
at pipe.c:423
423 pipe.c: No such file or directory.
(gdb) print tv
$1 = {tv_sec = 1438, tv_usec = 783700}
It seems a value related to uptime (system was up by about 24 minutes,
1440 seconds, when debugging).
The API documentation says that rt_pipe_read() accepts "a delay
expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
rt_pipe_read_timed(), that accepts "An absolute date expressed in clock
ticks", with a note saying "abs_timeout is interpreted as a multiple of
the Alchemy clock resolution" (I dont' understand this latter sentence).
If I'm not wrong, the "absolute date" would be a date expressed in
seconds after the epoch. Could the alchemy_rel_timeout() call in
include/alchemy/pipe.h calculate a wrong timeout?
Otherwise, what could be the problem?
Thanks in advance, regards
--
Mauro S.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_resume_pipe.tar.xz
Type: application/x-xz
Size: 1608 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20210925/3605e686/attachment.bin>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: rt_pipe_read(): timeout does not expire
2021-09-25 16:20 rt_pipe_read(): timeout does not expire Mauro S.
@ 2021-10-05 16:00 ` Jan Kiszka
2021-10-06 7:00 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2021-10-05 16:00 UTC (permalink / raw)
To: Mauro S., xenomai
On 25.09.21 18:20, Mauro S. via Xenomai wrote:
> Hi all,
>
> I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
>
> Please consider the attached simple test code.
>
> When I start the application, I never see the "Pipe task running" printf.
>
> When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
>
> Analyzing the code with gdb, the timeout in tv structure inside
> rt_pipe_read_timed() is the following
>
> (gdb) thread 13
> [Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
> 250 rtdm.c: No such file or directory.
> (gdb) bt
> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
> #1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
> buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
> from=from@entry=0x0,
> fromlen=fromlen@entry=0x0) at rtdm.c:343
> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
> at pipe.c:423
> #3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
> buf=0x7ffff7188d60, size=4, timeout=500000)
> at
> /opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
>
> #4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
> #5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
> #6 task_entry (arg=0x7ffff732ddc8) at task.c:219
> #7 0x00007ffff7faaca9 in thread_trampoline
> (arg=arg@entry=0x7fffffffe9c0) at internal.c:251
> #8 0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
> thread.c:123
> #9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
> pthread_create.c:477
> #10 0x00007ffff7e7edcf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) frame 2
> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
> at pipe.c:423
> 423 pipe.c: No such file or directory.
> (gdb) print tv
> $1 = {tv_sec = 1438, tv_usec = 783700}
>
> It seems a value related to uptime (system was up by about 24 minutes,
> 1440 seconds, when debugging).
Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the epoch.
That's at least true for I-pipe deployments.
>
> The API documentation says that rt_pipe_read() accepts "a delay
> expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
> rt_pipe_read_timed(), that accepts "An absolute date expressed in clock
> ticks", with a note saying "abs_timeout is interpreted as a multiple of
> the Alchemy clock resolution" (I dont' understand this latter sentence).
>
The Alchemy clock may not simply tick in single nanoseconds but may have
a courser resolution. That's why there is rt_timer_ns2ticks which you
are already using.
> If I'm not wrong, the "absolute date" would be a date expressed in
> seconds after the epoch. Could the alchemy_rel_timeout() call in
> include/alchemy/pipe.h calculate a wrong timeout?
> Otherwise, what could be the problem?
Cannot say yet, but I can confirm seeing the issue (too long timeout) as
well. Did you try to debug further already?
I'm also seeing lots of warnings with -Wconversion that are caused by
Xenomai. Adding an issue to our backlog.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: rt_pipe_read(): timeout does not expire
2021-10-05 16:00 ` Jan Kiszka
@ 2021-10-06 7:00 ` Jan Kiszka
2021-10-06 10:26 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2021-10-06 7:00 UTC (permalink / raw)
To: Mauro S., xenomai, Philippe Gerum
On 05.10.21 18:00, Jan Kiszka via Xenomai wrote:
> On 25.09.21 18:20, Mauro S. via Xenomai wrote:
>> Hi all,
>>
>> I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
>>
>> Please consider the attached simple test code.
>>
>> When I start the application, I never see the "Pipe task running" printf.
>>
>> When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
>>
>> Analyzing the code with gdb, the timeout in tv structure inside
>> rt_pipe_read_timed() is the following
>>
>> (gdb) thread 13
>> [Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>> 250 rtdm.c: No such file or directory.
>> (gdb) bt
>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>> #1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
>> buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
>> from=from@entry=0x0,
>> fromlen=fromlen@entry=0x0) at rtdm.c:343
>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>> at pipe.c:423
>> #3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
>> buf=0x7ffff7188d60, size=4, timeout=500000)
>> at
>> /opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
>>
>> #4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
>> #5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
>> #6 task_entry (arg=0x7ffff732ddc8) at task.c:219
>> #7 0x00007ffff7faaca9 in thread_trampoline
>> (arg=arg@entry=0x7fffffffe9c0) at internal.c:251
>> #8 0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
>> thread.c:123
>> #9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
>> pthread_create.c:477
>> #10 0x00007ffff7e7edcf in clone () at
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>> (gdb) frame 2
>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>> at pipe.c:423
>> 423 pipe.c: No such file or directory.
>> (gdb) print tv
>> $1 = {tv_sec = 1438, tv_usec = 783700}
>>
>> It seems a value related to uptime (system was up by about 24 minutes,
>> 1440 seconds, when debugging).
>
> Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the epoch.
> That's at least true for I-pipe deployments.
>
>>
>> The API documentation says that rt_pipe_read() accepts "a delay
>> expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
>> rt_pipe_read_timed(), that accepts "An absolute date expressed in clock
>> ticks", with a note saying "abs_timeout is interpreted as a multiple of
>> the Alchemy clock resolution" (I dont' understand this latter sentence).
>>
>
> The Alchemy clock may not simply tick in single nanoseconds but may have
> a courser resolution. That's why there is rt_timer_ns2ticks which you
> are already using.
>
>> If I'm not wrong, the "absolute date" would be a date expressed in
>> seconds after the epoch. Could the alchemy_rel_timeout() call in
>> include/alchemy/pipe.h calculate a wrong timeout?
>> Otherwise, what could be the problem?
>
> Cannot say yet, but I can confirm seeing the issue (too long timeout) as
> well. Did you try to debug further already?
>
Looks like rt_pipe_read_timed is wrong: SO_RCVTIMEO takes a relative
timeout to my reading of the man page and the code, but
rt_pipe_read_timed passed down an absolute value. This confuses me
because the function was like this for ages, so I might misread
something ATM. Philippe?
Jan
> I'm also seeing lots of warnings with -Wconversion that are caused by
> Xenomai. Adding an issue to our backlog.
>
> Jan
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: rt_pipe_read(): timeout does not expire
2021-10-06 7:00 ` Jan Kiszka
@ 2021-10-06 10:26 ` Jan Kiszka
2021-10-06 11:30 ` Mauro S.
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2021-10-06 10:26 UTC (permalink / raw)
To: Mauro S., xenomai, Philippe Gerum
On 06.10.21 09:00, Jan Kiszka via Xenomai wrote:
> On 05.10.21 18:00, Jan Kiszka via Xenomai wrote:
>> On 25.09.21 18:20, Mauro S. via Xenomai wrote:
>>> Hi all,
>>>
>>> I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
>>>
>>> Please consider the attached simple test code.
>>>
>>> When I start the application, I never see the "Pipe task running" printf.
>>>
>>> When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
>>>
>>> Analyzing the code with gdb, the timeout in tv structure inside
>>> rt_pipe_read_timed() is the following
>>>
>>> (gdb) thread 13
>>> [Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>> 250 rtdm.c: No such file or directory.
>>> (gdb) bt
>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>> #1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
>>> buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
>>> from=from@entry=0x0,
>>> fromlen=fromlen@entry=0x0) at rtdm.c:343
>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>> at pipe.c:423
>>> #3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
>>> buf=0x7ffff7188d60, size=4, timeout=500000)
>>> at
>>> /opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
>>>
>>> #4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
>>> #5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
>>> #6 task_entry (arg=0x7ffff732ddc8) at task.c:219
>>> #7 0x00007ffff7faaca9 in thread_trampoline
>>> (arg=arg@entry=0x7fffffffe9c0) at internal.c:251
>>> #8 0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
>>> thread.c:123
>>> #9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
>>> pthread_create.c:477
>>> #10 0x00007ffff7e7edcf in clone () at
>>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>>> (gdb) frame 2
>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>> at pipe.c:423
>>> 423 pipe.c: No such file or directory.
>>> (gdb) print tv
>>> $1 = {tv_sec = 1438, tv_usec = 783700}
>>>
>>> It seems a value related to uptime (system was up by about 24 minutes,
>>> 1440 seconds, when debugging).
>>
>> Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the epoch.
>> That's at least true for I-pipe deployments.
>>
>>>
>>> The API documentation says that rt_pipe_read() accepts "a delay
>>> expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
>>> rt_pipe_read_timed(), that accepts "An absolute date expressed in clock
>>> ticks", with a note saying "abs_timeout is interpreted as a multiple of
>>> the Alchemy clock resolution" (I dont' understand this latter sentence).
>>>
>>
>> The Alchemy clock may not simply tick in single nanoseconds but may have
>> a courser resolution. That's why there is rt_timer_ns2ticks which you
>> are already using.
>>
>>> If I'm not wrong, the "absolute date" would be a date expressed in
>>> seconds after the epoch. Could the alchemy_rel_timeout() call in
>>> include/alchemy/pipe.h calculate a wrong timeout?
>>> Otherwise, what could be the problem?
>>
>> Cannot say yet, but I can confirm seeing the issue (too long timeout) as
>> well. Did you try to debug further already?
>>
>
> Looks like rt_pipe_read_timed is wrong: SO_RCVTIMEO takes a relative
> timeout to my reading of the man page and the code, but
> rt_pipe_read_timed passed down an absolute value. This confuses me
> because the function was like this for ages, so I might misread
> something ATM. Philippe?
>
It is definitely broken in alchemy, I've created
https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/30 to track the
to-dos. Any helping hand welcome.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: rt_pipe_read(): timeout does not expire
2021-10-06 10:26 ` Jan Kiszka
@ 2021-10-06 11:30 ` Mauro S.
2021-10-18 7:06 ` Mauro S.
0 siblings, 1 reply; 6+ messages in thread
From: Mauro S. @ 2021-10-06 11:30 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai, Philippe Gerum
Il 06/10/21 12:26, Jan Kiszka ha scritto:
> On 06.10.21 09:00, Jan Kiszka via Xenomai wrote:
>> On 05.10.21 18:00, Jan Kiszka via Xenomai wrote:
>>> On 25.09.21 18:20, Mauro S. via Xenomai wrote:
>>>> Hi all,
>>>>
>>>> I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
>>>>
>>>> Please consider the attached simple test code.
>>>>
>>>> When I start the application, I never see the "Pipe task running" printf.
>>>>
>>>> When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
>>>>
>>>> Analyzing the code with gdb, the timeout in tv structure inside
>>>> rt_pipe_read_timed() is the following
>>>>
>>>> (gdb) thread 13
>>>> [Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
>>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>>> 250 rtdm.c: No such file or directory.
>>>> (gdb) bt
>>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>>> #1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
>>>> buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
>>>> from=from@entry=0x0,
>>>> fromlen=fromlen@entry=0x0) at rtdm.c:343
>>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>>> at pipe.c:423
>>>> #3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
>>>> buf=0x7ffff7188d60, size=4, timeout=500000)
>>>> at
>>>> /opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
>>>>
>>>> #4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
>>>> #5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
>>>> #6 task_entry (arg=0x7ffff732ddc8) at task.c:219
>>>> #7 0x00007ffff7faaca9 in thread_trampoline
>>>> (arg=arg@entry=0x7fffffffe9c0) at internal.c:251
>>>> #8 0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
>>>> thread.c:123
>>>> #9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
>>>> pthread_create.c:477
>>>> #10 0x00007ffff7e7edcf in clone () at
>>>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>>>> (gdb) frame 2
>>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>>> at pipe.c:423
>>>> 423 pipe.c: No such file or directory.
>>>> (gdb) print tv
>>>> $1 = {tv_sec = 1438, tv_usec = 783700}
>>>>
>>>> It seems a value related to uptime (system was up by about 24 minutes,
>>>> 1440 seconds, when debugging).
>>>
>>> Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the epoch.
>>> That's at least true for I-pipe deployments.
>>>
>>>>
>>>> The API documentation says that rt_pipe_read() accepts "a delay
>>>> expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
>>>> rt_pipe_read_timed(), that accepts "An absolute date expressed in clock
>>>> ticks", with a note saying "abs_timeout is interpreted as a multiple of
>>>> the Alchemy clock resolution" (I dont' understand this latter sentence).
>>>>
>>>
>>> The Alchemy clock may not simply tick in single nanoseconds but may have
>>> a courser resolution. That's why there is rt_timer_ns2ticks which you
>>> are already using.
>>>
>>>> If I'm not wrong, the "absolute date" would be a date expressed in
>>>> seconds after the epoch. Could the alchemy_rel_timeout() call in
>>>> include/alchemy/pipe.h calculate a wrong timeout?
>>>> Otherwise, what could be the problem?
>>>
>>> Cannot say yet, but I can confirm seeing the issue (too long timeout) as
>>> well. Did you try to debug further already?
>>>
>>
>> Looks like rt_pipe_read_timed is wrong: SO_RCVTIMEO takes a relative
>> timeout to my reading of the man page and the code, but
>> rt_pipe_read_timed passed down an absolute value. This confuses me
>> because the function was like this for ages, so I might misread
>> something ATM. Philippe?
>>
>
> It is definitely broken in alchemy, I've created
> https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/30 to track the
> to-dos. Any helping hand welcome.
>
> Jan
>
Hi Jan,
sorry for the delay.
Thank you for your explanations and your analysis.
Mauro
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: rt_pipe_read(): timeout does not expire
2021-10-06 11:30 ` Mauro S.
@ 2021-10-18 7:06 ` Mauro S.
0 siblings, 0 replies; 6+ messages in thread
From: Mauro S. @ 2021-10-18 7:06 UTC (permalink / raw)
To: xenomai
Il 06/10/21 13:30, Mauro S. via Xenomai ha scritto:
> Il 06/10/21 12:26, Jan Kiszka ha scritto:
>> On 06.10.21 09:00, Jan Kiszka via Xenomai wrote:
>>> On 05.10.21 18:00, Jan Kiszka via Xenomai wrote:
>>>> On 25.09.21 18:20, Mauro S. via Xenomai wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.
>>>>>
>>>>> Please consider the attached simple test code.
>>>>>
>>>>> When I start the application, I never see the "Pipe task running"
>>>>> printf.
>>>>>
>>>>> When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.
>>>>>
>>>>> Analyzing the code with gdb, the timeout in tv structure inside
>>>>> rt_pipe_read_timed() is the following
>>>>>
>>>>> (gdb) thread 13
>>>>> [Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
>>>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>>>> 250 rtdm.c: No such file or directory.
>>>>> (gdb) bt
>>>>> #0 0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
>>>>> msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
>>>>> #1 0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
>>>>> buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
>>>>> from=from@entry=0x0,
>>>>> fromlen=fromlen@entry=0x0) at rtdm.c:343
>>>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>>>> at pipe.c:423
>>>>> #3 0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
>>>>> buf=0x7ffff7188d60, size=4, timeout=500000)
>>>>> at
>>>>> /opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72
>>>>>
>>>>>
>>>>> #4 0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
>>>>> #5 0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at
>>>>> task.c:237
>>>>> #6 task_entry (arg=0x7ffff732ddc8) at task.c:219
>>>>> #7 0x00007ffff7faaca9 in thread_trampoline
>>>>> (arg=arg@entry=0x7fffffffe9c0) at internal.c:251
>>>>> #8 0x00007ffff7f8b93e in cobalt_thread_trampoline
>>>>> (p=0x7fffffffe820) at
>>>>> thread.c:123
>>>>> #9 0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
>>>>> pthread_create.c:477
>>>>> #10 0x00007ffff7e7edcf in clone () at
>>>>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>>>>> (gdb) frame 2
>>>>> #2 0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
>>>>> buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
>>>>> at pipe.c:423
>>>>> 423 pipe.c: No such file or directory.
>>>>> (gdb) print tv
>>>>> $1 = {tv_sec = 1438, tv_usec = 783700}
>>>>>
>>>>> It seems a value related to uptime (system was up by about 24 minutes,
>>>>> 1440 seconds, when debugging).
>>>>
>>>> Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the
>>>> epoch.
>>>> That's at least true for I-pipe deployments.
>>>>
>>>>>
>>>>> The API documentation says that rt_pipe_read() accepts "a delay
>>>>> expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
>>>>> rt_pipe_read_timed(), that accepts "An absolute date expressed in
>>>>> clock
>>>>> ticks", with a note saying "abs_timeout is interpreted as a
>>>>> multiple of
>>>>> the Alchemy clock resolution" (I dont' understand this latter
>>>>> sentence).
>>>>>
>>>>
>>>> The Alchemy clock may not simply tick in single nanoseconds but may
>>>> have
>>>> a courser resolution. That's why there is rt_timer_ns2ticks which you
>>>> are already using.
>>>>
>>>>> If I'm not wrong, the "absolute date" would be a date expressed in
>>>>> seconds after the epoch. Could the alchemy_rel_timeout() call in
>>>>> include/alchemy/pipe.h calculate a wrong timeout?
>>>>> Otherwise, what could be the problem?
>>>>
>>>> Cannot say yet, but I can confirm seeing the issue (too long
>>>> timeout) as
>>>> well. Did you try to debug further already?
>>>>
>>>
>>> Looks like rt_pipe_read_timed is wrong: SO_RCVTIMEO takes a relative
>>> timeout to my reading of the man page and the code, but
>>> rt_pipe_read_timed passed down an absolute value. This confuses me
>>> because the function was like this for ages, so I might misread
>>> something ATM. Philippe?
>>>
>>
>> It is definitely broken in alchemy, I've created
>> https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/30 to track the
>> to-dos. Any helping hand welcome.
>>
>> Jan
>>
>
>
> Hi Jan,
>
> sorry for the delay.
>
> Thank you for your explanations and your analysis.
>
> Mauro
>
Hi Jan,
I confirm that your patchset has fixed the rt_pipe part.
Thanks, regards
--
Mauro S.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-18 7:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-25 16:20 rt_pipe_read(): timeout does not expire Mauro S.
2021-10-05 16:00 ` Jan Kiszka
2021-10-06 7:00 ` Jan Kiszka
2021-10-06 10:26 ` Jan Kiszka
2021-10-06 11:30 ` Mauro S.
2021-10-18 7:06 ` Mauro S.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.