[Xenomai] [Posix] I/O multiplexing with select

[Xenomai] [Posix] I/O multiplexing with select

[alex alex]

xenomai = 2.6.2.1
linux kernel = 3.5.7
arch = x86

Hello everyone,

I'm working on a program that uses both a TCP with linux socket and a
real-time communication module based on rtnet using rtdm.
My requirement is to use the select function with this 2 types of
communication.
To make this works, I created a wrap on select that is calling a function ("
wrap_select") to create two threads in detached mode: the first for linux
descriptors and the second for rtdm descriptors.
After the creation of threads, the "wrap_select" function that waits
for a semaphore.
This semaphore is posted by the thread which select is released.
Then the function "wrap_select" destroy the two functions with
pthread_cancel.

This mechanisme works fine but after a certain number of calls, creating
thread with pthread_create fails with the following error: errno = EAGAIN,
Insufficient memory exists in the system heap to create a new thread,
Increase.
It seems there was a limit to the thread creation...

1 - Have you any idea about how to work around this problem?

2 - A solution would be to create two threads to handle rtdm select and
linux without destroying them each time.
But in this case I have to report to the select which thread is still blocking
its release and I dont know how I can do that.

3- Maybe there is a better solution or maybe this problem has already been
encountered and solved by one of you?

Regards,

Alexandre

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/08/2013 03:53 PM, alex alex wrote:

> xenomai = 2.6.2.1
> linux kernel = 3.5.7
> arch = x86
> 
> Hello everyone,
> 
> I'm working on a program that uses both a TCP with linux socket and a
> real-time communication module based on rtnet using rtdm.
> My requirement is to use the select function with this 2 types of
> communication.
> To make this works, I created a wrap on select that is calling a function ("
> wrap_select") to create two threads in detached mode: the first for linux
> descriptors and the second for rtdm descriptors.
> After the creation of threads, the "wrap_select" function that waits
> for a semaphore.
> This semaphore is posted by the thread which select is released.
> Then the function "wrap_select" destroy the two functions with
> pthread_cancel.


This defeats the purpose of having a select service which works in
primary mode: your select service switches to secondary mode by calling
pthread_create. Instead of doing this, I would advise using a message
queue, and select from it from the xenomai thread. Besides, creating
threads every time is a bit bad for latencies.

> 
> This mechanisme works fine but after a certain number of calls, creating
> thread with pthread_create fails with the following error: errno = EAGAIN,
> Insufficient memory exists in the system heap to create a new thread,
> Increase.
> It seems there was a limit to the thread creation...
> 
> 1 - Have you any idea about how to work around this problem?


You do not want to work around the problem, you want to fix it. There
is probably some bit missing somewhere to get the thread control block
destroyed when a detached thread dies.

> 
> 2 - A solution would be to create two threads to handle rtdm select and
> linux without destroying them each time.
> But in this case I have to report to the select which thread is still blocking
> its release and I dont know how I can do that.
> 
> 3- Maybe there is a better solution or maybe this problem has already been
> encountered and solved by one of you?


Yes, I have already done that, and tried and describe it in the
following text:

http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#I.2FO_multiplexing_with_select

The posix binding for Xenomai real-time pipes has been created in the
mean-time: it is the xddp sockets.

-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

>You do not want to work around the problem, you want to fix it. There
>is probably some bit missing somewhere to get the thread control block
>destroyed when a detached thread dies.

Yes, one variable was not freed...

>Yes, I have already done that, and tried and describe it in the
>following text:
>
>http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#I.2FO_>multiplexing_with_select<http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#I.2FO_multiplexing_with_select>
>
>The posix binding for Xenomai real-time pipes has been created in the
>mean-time: it is the xddp sockets.

If I well understand, your reimplemented select calls a function that
communicates with a thread dealing with linux files descriptors through the
XDDP protocol.
At first you have separated linux and rtdm files descriptor of the select
mask. Then you send the linux files descriptor to the linux thread with the
socket.
The linux thread do its select with these files descriptor and the
pseudo-device files /dev/rtp <minor>.
The xenomai thread do its select with the rtdm files descriptor files and the
file descriptor of the socket bounded to the XDDP ports.
When a thread has its select realesed, it informs the other through the pipe
which allows to free its select.

Is that correct?

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/08/2013 10:34 PM, alex alex wrote:

>> You do not want to work around the problem, you want to fix it. There
>> is probably some bit missing somewhere to get the thread control block
>> destroyed when a detached thread dies.
> 
> Yes, one variable was not freed...
> 
>> Yes, I have already done that, and tried and describe it in the
>> following text:
>>
>> http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#I.2FO_>multiplexing_with_select<http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#I.2FO_multiplexing_with_select>
>>
>> The posix binding for Xenomai real-time pipes has been created in the
>> mean-time: it is the xddp sockets.
> 
> If I well understand, your reimplemented select calls a function that
> communicates with a thread dealing with linux files descriptors through the
> XDDP protocol.


No, I used select() in a thread running in primary mode, and
__real_select() in a thread running with the SCHED_OTHER policy, so most
of the time in secondary mode. Every time __real_select returned an
event for a plain Linux file descriptor which was relevant for the
thread running in primary mode, a message was sent to it through a posix
message queue, which descriptor was included in the set of file
descriptors passed to the select() call.

The XDDP socket would be used the other way around: to wake up the
thread blocked in __real_select and inform it of some event detected by
the thread running in primary mode, but I never had to implement that.

I never tried to hide this behaviour behind a higher level "select", as
I wanted the thread calling the select() service to stay in primary
mode, and processing some events on linux file descriptors required
services to be run in secondary mode, so, the two loops had to be kept
separate, and I believe in fact it is always the case.

-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

Thank you, I'll try to implement it with the messages queue and socket XDDP.
I think it's safer than the older method (ie by creating two thread each
call to select). It worked but an exception happened after a while .

[ 5011.991938] BUG: Unhandled exception over domain Xenomai at 0xc1334a4e -
switching to ROOT
[ 5011.991943] Pid: 30922, comm: RECOR Tainted: G           O 3.5.7-xenomai
#1
[ 5011.991944] Call Trace:
[ 5011.991961]  [<c101dee4>] __ipipe_handle_exception+0x204/0x210
[ 5011.991965]  [<c1334a4e>] ? strncpy+0x1e/0x40
[ 5011.991969]  [<c16134ef>] error_code+0x5f/0x6c
[ 5011.991971]  [<c1334a4e>] ? strncpy+0x1e/0x40
[ 5011.991977]  [<c1164841>] __pthread_set_name_np+0x81/0xb0
[ 5011.992006]  [<c10b6300>] ? __ipipe_post_work_root+0x90/0xe0
[ 5011.992009]  [<c1612ae4>] ? _raw_spin_unlock_irqrestore+0x24/0x50
[ 5011.992013]  [<c110c918>] hisyscall_event+0x178/0x380
[ 5011.992017]  [<c10b751a>] ipipe_syscall_hook+0x3a/0x50
[ 5011.992020]  [<c10b5e0d>] __ipipe_notify_syscall+0x9d/0x100
[ 5011.992023]  [<c101e077>] __ipipe_syscall_root+0x37/0xd0
[ 5011.992027]  [<c1618ef8>] sysenter_past_esp+0x55/0x6c
[ 5011.992031] BUG: unable to handle kernel NULL pointer dereference at
000002f4
[ 5011.992061] IP: [<c1334a4e>] strncpy+0x1e/0x40
[ 5011.992092] *pdpt = 000000001f113001 *pde = 0000000000000000
[ 5011.992114] Oops: 0002 [#1] PREEMPT SMP
[ 5011.992132] Modules linked in: de_pilote(O) pml_pilote(O) rt_e1000e(O)
rt_loopback(O) rtnet(O) nls_iso8859_1 nls_cp437 vfat fat usb_storage
tda1004x saa7134_dvb videobuf_dvb dvb_core saa7134_alsa snd_hda_codec_hdmi
snd_hda_codec_realtek tda827x tda8290 tuner coretemp kvm aesni_intel cryptd
aes_i586 mxm_wmi hid_generic eeepc_wmi asus_wmi sparse_keymap snd_usb_audio
rfcomm snd_hda_intel snd_hda_codec saa7134 bnep serio_raw arc4 bluetooth
snd_pcm microcode snd_hwdep snd_usbmidi_lib snd_seq_midi snd_seq_midi_event
parport_pc ath9k ppdev mac80211 rc_core snd_rawmidi snd_seq videobuf_dma_sg
videobuf_core v4l2_common snd_timer ath9k_common videodev snd_seq_device
tveeprom ath9k_hw ath lpc_ich usbhid hid cfg80211 snd mac_hid radeon ttm
i915 binfmt_misc drm_kms_helper wmi soundcore drm snd_page_alloc mei
i2c_algo_bit video lp parport 8139too 8139cp [last unloaded: de_pilote]
[ 5011.992474]
[ 5011.992481] Pid: 30922, comm: RECOR Tainted: G           O 3.5.7-xenomai
#1 System manufacturer System Product Name/P8Z77-V
[ 5011.992520] EIP: 0060:[<c1334a4e>] EFLAGS: 00210216 CPU: 0
[ 5011.992538] EIP is at strncpy+0x1e/0x40
[ 5011.992551] EAX: 00000273 EBX: 000002f4 ECX: 0000000f EDX: ef5e1efc
[ 5011.992571] ESI: ef5e1efd EDI: 000002f4 EBP: ef5e1ef4 ESP: ef5e1ee8
[ 5011.992591]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 5011.992608] CR0: 8005003b CR2: 000002f4 CR3: 1f112000 CR4: 001007f0
[ 5011.992628] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 5011.992648] DR6: ffff0ff0 DR7: 00000400
[ 5011.992661] Process RECOR (pid: 30922, ti=ef5e0000 task=ec5b4ce0
task.ti=ef5e0000)
[ 5011.992685] I-pipe domain Linux
[ 5011.992695] Stack:
[ 5011.992702]  f8436800 00000000 00000000 ef5e1f2c c1164841 656c6573
6c5f7463 78756e69
[ 5011.992737]  c10b6300 ef5e1f14 c1612ae4 ef5e1f3c 00064f4c b6c31b40
ec437c00 0000000a
[ 5011.992771]  00000000 ef5e1f60 c110c918 ef5e1fb4 df1359b0 ef5e1f84
ef5e1fb4 00000038
[ 5011.992806] Call Trace:
[ 5011.992817]  [<c1164841>] __pthread_set_name_np+0x81/0xb0
[ 5011.992857]  [<c10b6300>] ? __ipipe_post_work_root+0x90/0xe0
[ 5011.992876]  [<c1612ae4>] ? _raw_spin_unlock_irqrestore+0x24/0x50
[ 5011.992898]  [<c110c918>] hisyscall_event+0x178/0x380
[ 5011.992925]  [<c10b751a>] ipipe_syscall_hook+0x3a/0x50
[ 5011.992968]  [<c10b5e0d>] __ipipe_notify_syscall+0x9d/0x100
[ 5011.992988]  [<c101e077>] __ipipe_syscall_root+0x37/0xd0
[ 5011.993007]  [<c1618ef8>] sysenter_past_esp+0x55/0x6c
[ 5011.993023] Code: 7d fc 89 ec 5d c3 8d b4 26 00 00 00 00 55 89 e5 83 ec
0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 c3 89 d6 89 c7 49 78 08 ac
<aa> 84 c0 75 f7 f3 aa 89 d8 8b 75 f8 8b 5d f4 8b 7d fc 89 ec 5d
[ 5011.993183] EIP: [<c1334a4e>] strncpy+0x1e/0x40 SS:ESP 0068:ef5e1ee8
[ 5011.993207] CR2: 00000000000002f4
[ 5011.996438] ---[ end trace 5b267698c8ec1270 ]---


This may be due, as you said, that pthread_create switches to secondary.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

It's implemented and it's works fine.
Thanks for the tips, again :)

Regards,

Alexandre

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/08/2013 11:30 PM, alex alex wrote:

> This may be due, as you said, that pthread_create switches to secondary.


No, a switch to secondary mode does not create a bug. It looks like an
invalid address gets passed to pthread_set_name_np, either source or
destination address. Could you reduce the faulting program to a program
as simple as possible triggering the bug?

-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

 Could you reduce the faulting program to a program

> as simple as possible triggering the bug?
>
>
Using the new implementation of select, I don't have this bug anymore
. Thedifferent is
that with the former I called periodically pthread_set_name_np).
I'll try to reproduce this bug with a simple program.

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 03:13 PM, alex alex wrote:

>  Could you reduce the faulting program to a program
> 
>> as simple as possible triggering the bug?
>>
>>
> Using the new implementation of select, I don't have this bug anymore
> . Thedifferent is
> that with the former I called periodically pthread_set_name_np).


I you call pthread_set_name_np for a thread that may not exist, this is 
an issue which has already been fixed:

http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=84b3b4ee50d2e2aa5ebd257a02d330994de674a3;hp=2a29477bbad419f5570e660e90f918c0627c893e


-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

I you call pthread_set_name_np for a thread that may not exist, this is

> an issue which has already been fixed:
>
>
I have tried to used pthread_set_name_np with a thread that may not exist
but it correctly returns ESRCH.

I've also tried to reproduce this bug by creating and canceling a thread in
a loop, but I can not have this bug anymore.

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 04:09 PM, alex alex wrote:

> I you call pthread_set_name_np for a thread that may not exist, this is
> 
>> an issue which has already been fixed:
>>
>>
> I have tried to used pthread_set_name_np with a thread that may not exist
> but it correctly returns ESRCH.
> 
> I've also tried to reproduce this bug by creating and canceling a thread in
> a loop, but I can not have this bug anymore.


Ok, are you sure that the string you passed to pthread_set_name_np could
not have been overwritten in the mean time? For instance by passing to
the thread an argument which resides on the caller stack. Like for instance:

void *thread(void *cookie)
{
	pthread_set_name_np(pthread_self(), (char *)cookie);
	
	/* ... */
}

void create_thread(void)
{
	char name[]= "name";
	pthread_t tid;

	pthread_create(&tid, NULL, thread, name);
}

int main(void)
{
	create_thread();

	/* ... */

}

-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

Sorry for the last mail..

Here is what I've done.

void *thread2(void *cookie)
{
        /* ... */
}

Task create_thread(pthread_t* t, const char* name, void *(*)(void *) funct,
void* arg)
{
        /* ... */
        pthread_create(t, ..., funct, arg);
        /* ... */

        pthread_set_name_np(t, name);
        /* ... */
}

int *thread(void *cookie)
{
    pthread_t tid1;
    pthread_t tid2;

    create_thread(&tid1, "name1", thread2, NULL);
    create_thread(&tid2, "name2", thread2, NULL);

    /* ... */

    pthread_cancel(&tid1);
    pthread_cancel(&tid2);

     /* ... */
}

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 04:51 PM, alex alex wrote:

> Sorry for the last mail..
> 
> Here is what I've done.


I am interested in the code that does not work, is this the one? This
may trigger the bug that was fixed since 2.6.2.1 if the created thread
dies before pthread_set_name_np is called.

-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

So here is the code:

void *thread2(void *cookie)
{
        /* ... */
}

int create_thread(pthread_t* t, const char* name, void *(*)(void *) funct,
void* arg)
{
        /* ... */
        pthread_create(t, ..., funct, arg);
        /* ... */

        pthread_set_name_np(t, name);
        /* ... */
}

int *thread(void *cookie)
{
    pthread_t tid1;
    pthread_t tid2;

    create_thread(&tid1, "name1", thread2, NULL);
    create_thread(&tid2, "name2", thread2, NULL);

    /* ... */

    pthread_cancel(&tid1);
    pthread_cancel(&tid2);

     /* ... */
}

The name "name1" "name2" are not stored in a variable.

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 05:35 PM, alex alex wrote:

> So here is the code:
> 
> void *thread2(void *cookie)
> {
>         /* ... */
> }
> 
> int create_thread(pthread_t* t, const char* name, void *(*)(void *) funct,
> void* arg)
> {
>         /* ... */
>         pthread_create(t, ..., funct, arg);
>         /* ... */
> 
>         pthread_set_name_np(t, name);
>         /* ... */
> }
> 
> int *thread(void *cookie)
> {
>     pthread_t tid1;
>     pthread_t tid2;
> 
>     create_thread(&tid1, "name1", thread2, NULL);
>     create_thread(&tid2, "name2", thread2, NULL);
> 
>     /* ... */
> 
>     pthread_cancel(&tid1);
>     pthread_cancel(&tid2);
> 
>      /* ... */
> }
> 
> The name "name1" "name2" are not stored in a variable.


Ok, could you test the problematic code with the current contents of
xenomai git ?
git://git.xenomai.org/xenomai-2.6.git
branch master
-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

>
> Ok, could you test the problematic code with the current contents of
> xenomai git ?
> git://git.xenomai.org/xenomai-2.6.git
> branch master
> --
>

OK, but the patch you mentioned :
http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=84b3b4ee50d2e2aa5ebd257a02d330994de674a3;hp=2a29477bbad419f5570e660e90f918c0627c893e

is already in my xenomai tree.
Have you done other changes with the pthread_name_set_np ?

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 05:46 PM, alex alex wrote:

>>
>> Ok, could you test the problematic code with the current contents of
>> xenomai git ?
>> git://git.xenomai.org/xenomai-2.6.git
>> branch master
>> --
>>
> 
> OK, but the patch you mentioned :
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=84b3b4ee50d2e2aa5ebd257a02d330994de674a3;hp=2a29477bbad419f5570e660e90f918c0627c893e
> 
> is already in my xenomai tree.
> Have you done other changes with the pthread_name_set_np ?


No, could you show us a dissassembly of the function strncpy ?(on the
exact kernel which has the bug, if you recompiled the kernel, please
trigger the bug again to get the oops message that corresponds to it).


-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

vmlinuz is a zImage, or bzImage, we are interested in vmlinux, the ELF

> image you get when compiling the kernel, at the top of the build tree.
>
>
I had no longer the vmlinux file so I have extract the vmlinuz from the
/boot directory with "linux-headers-3.5.7-xenomai/
scripts/extract-vmlinux" now I have a vmlinux file but I there are only
assembly code like that :


....

c107eb4c:    8d 74 26 00              lea    0x0(%esi,%eiz,1),%esi
c107eb50:    55                       push   %ebp
c107eb51:    89 e5                    mov    %esp,%ebp
c107eb53:    57                       push   %edi
c107eb54:    56                       push   %esi
c107eb55:    53                       push   %ebx
c107eb56:    83 ec 10                 sub    $0x10,%esp
c107eb59:    e8 6a a9 59 00           call   0xc16194c8
c107eb5e:    8b 1d 6c 58 9f c1        mov    0xc19f586c,%ebx
c107eb64:    89 45 e4                 mov    %eax,-0x1c(%ebp

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 06:44 PM, alex alex wrote:

> vmlinuz is a zImage, or bzImage, we are interested in vmlinux, the ELF
> 
>> image you get when compiling the kernel, at the top of the build tree.
>>
>>
> I had no longer the vmlinux file so I have extract the vmlinuz from the
> /boot directory with "linux-headers-3.5.7-xenomai/
> scripts/extract-vmlinux" now I have a vmlinux file but I there are only
> assembly code like that :
> 
> 
> ....
> 
> c107eb4c:    8d 74 26 00              lea    0x0(%esi,%eiz,1),%esi
> c107eb50:    55                       push   %ebp
> c107eb51:    89 e5                    mov    %esp,%ebp
> c107eb53:    57                       push   %edi
> c107eb54:    56                       push   %esi
> c107eb55:    53                       push   %ebx
> c107eb56:    83 ec 10                 sub    $0x10,%esp
> c107eb59:    e8 6a a9 59 00           call   0xc16194c8
> c107eb5e:    8b 1d 6c 58 9f c1        mov    0xc19f586c,%ebx
> c107eb64:    89 45 e4                 mov    %eax,-0x1c(%ebp


please put the vmlinux file on an ftp or http server somewhere.


-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

vmlinux file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmlinux
Type: application/octet-stream
Size: 11189780 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130509/0255686a/attachment.obj>

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 06:56 PM, alex alex wrote:

> vmlinux file
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: vmlinux
> Type: application/octet-stream
> Size: 11189780 bytes
> Desc: not available
> URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130509/0255686a/attachment.obj>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 


Please try the following patch:

diff --git a/ksrc/skins/posix/syscall.c b/ksrc/skins/posix/syscall.c
index 49ed764..8ffd1ad 100644
--- a/ksrc/skins/posix/syscall.c
+++ b/ksrc/skins/posix/syscall.c
@@ -437,8 +437,10 @@ static int __pthread_set_name_np(struct pt_regs *regs)
 	k_tid = __pthread_find(&hkey);
 	if (k_tid) {
 		p = xnthread_user_task(&k_tid->threadbase);
-		strncpy(p->comm, name, sizeof(p->comm));
-		p->comm[sizeof(p->comm) - 1] = '\0';
+		if (p) {
+			strncpy(p->comm, name, sizeof(p->comm));
+			p->comm[sizeof(p->comm) - 1] = '\0';
+		}
 	}

 	return -pthread_set_name_np(k_tid, name);


-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[Gilles Chanteperdrix]

On 05/09/2013 06:56 PM, alex alex wrote:

> vmlinux file
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: vmlinux
> Type: application/octet-stream
> Size: 11189780 bytes
> Desc: not available
> URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130509/0255686a/attachment.obj>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 


Please try that one instead:

diff --git a/ksrc/skins/posix/syscall.c b/ksrc/skins/posix/syscall.c
index 49ed764..6fbe4c4 100644
--- a/ksrc/skins/posix/syscall.c
+++ b/ksrc/skins/posix/syscall.c
@@ -435,11 +435,6 @@ static int __pthread_set_name_np(struct pt_regs *regs)
 	hkey.u_tid = __xn_reg_arg1(regs);
 	hkey.mm = current->mm;
 	k_tid = __pthread_find(&hkey);
-	if (k_tid) {
-		p = xnthread_user_task(&k_tid->threadbase);
-		strncpy(p->comm, name, sizeof(p->comm));
-		p->comm[sizeof(p->comm) - 1] = '\0';
-	}
 
 	return -pthread_set_name_np(k_tid, name);
 }
diff --git a/ksrc/skins/posix/thread.c b/ksrc/skins/posix/thread.c
index 01fc699..78f5634 100644
--- a/ksrc/skins/posix/thread.c
+++ b/ksrc/skins/posix/thread.c
@@ -715,6 +715,9 @@ int pthread_set_mode_np(int clrmask, int setmask)
  */
 int pthread_set_name_np(pthread_t thread, const char *name)
 {
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+	struct task_struct *p;
+#endif /* CONFIG_XENO_OPT_PERVASIVE */
 	spl_t s;
 
 	xnlock_get_irqsave(&nklock, s);
@@ -727,6 +730,14 @@ int pthread_set_name_np(pthread_t thread, const char *name)
 	snprintf(xnthread_name(&thread->threadbase), XNOBJECT_NAME_LEN, "%s",
 		 name);
 
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+	p = xnthread_user_task(&thread->threadbase);
+	if (p) {
+		strncpy(p->comm, name, sizeof(p->comm));
+		p->comm[sizeof(p->comm) - 1] = '\0';
+	}
+#endif /* CONFIG_XENO_OPT_PERVASIVE */
+
 	xnlock_put_irqrestore(&nklock, s);
 
 	return 0;


-- 
                                                                Gilles.

Re: [Xenomai] [Posix] I/O multiplexing with select

[alex alex]

Sorry for the delay.

Your patch works fine, the program doesn't crash but instead
pthread_set_name_np returned "No such process".