[Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Pierre.QUELIN]

[-- Attachment #1: Type: text/plain, Size: 8385 bytes --]



Dear,

I am trying to debug a posix application and I noticed what I think is a
bug in the method pthread_cond_wait (). it returns EPERM when the
application is started with gdb.
Could you please help me to understand what is wrong or locate the bug?

Best regards.

Pierre Quélin

------------------------------------
Configuration
------------------------------------
Ubuntu 10.10
Linux xenomai 2.6.35.7-core2xeon-adeos-2.8-00 #1 SMP PREEMPT Mon Dec 6
13:37:41 CET 2010 i686 GNU/Linux

Gnu C 4.4.4-14ubuntu5)
GNU gdb (GDB) 7.2-ubuntu
Gnu make 3.81
util-linux ng 2.17.2)
mount ng 2.17.2 (with libblkid and selinux support)
module-init-tools 3.12
e2fsprogs 1.41.12
Linux C Library 2.12.1
Dynamic linker (ldd) 2.12.1
Procps 3.2.8
Net-tools 1.60
Kbd 1.15
Sh-utils 8.5
Modules Loaded ip6table_filter ip6_tables binfmt_misc ipt_MASQUERADE
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack
ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel
kvm parport_pc ppdev arc4 rt73usb crc_itu_t rt2x00usb rt2x00lib led_class
i3200_edac edac_core mac80211 lp psmouse serio_raw cfg80211 parport hed
floppy e1000 e1000e

------------------------------------
Code
------------------------------------
#include <sys/mman.h> /* line 0 */
#include <pthread.h>

void* bodyA(void*)
{
   pthread_cond_t cond;
   pthread_mutex_t mutex;
   pthread_mutexattr_t attr;
   int res;

   res = pthread_mutexattr_init( &attr );
   res = pthread_mutexattr_setprotocol( &attr, PTHREAD_PRIO_INHERIT );
   res = pthread_mutex_init( &mutex, &attr );
   res = pthread_mutexattr_destroy( &attr );
   res = pthread_cond_init( &cond, NULL );

   bool state = false;
   res = pthread_mutex_lock( &mutex );
   while ( !state )
   {
      res = pthread_cond_wait( &cond, &mutex );
      if ( 0 != res )
      {
         res = pthread_mutex_unlock( &mutex );
         return (void*)-1;
      }
      else
      {
         (void)res;
      }
   }
   state = true;
   res = pthread_mutex_unlock( &mutex );

   return 0;
};

void* bodyB(void*)
{
   pthread_cond_t cond;
   pthread_mutex_t mutex;
   pthread_mutexattr_t attr;
   int res;

   res = pthread_mutexattr_init( &attr );
   res = pthread_mutexattr_setprotocol( &attr, PTHREAD_PRIO_INHERIT );
   res = pthread_mutex_init( &mutex, &attr );
   res = pthread_mutexattr_destroy( &attr );
   res = pthread_cond_init( &cond, NULL );

   bool state = false;
   res = pthread_mutex_lock( &mutex );
   while ( !state )
   {
      res = pthread_cond_wait( &cond, &mutex );
      if ( 0 != res )
      {
         res = pthread_mutex_unlock( &mutex );
         return (void*)-1;
      }
      else
      {
         (void)res;
      }
   }
   state = true;
   res = pthread_mutex_unlock( &mutex );

   return 0;
};

#define DEFAULT_PRIORITY 100
#define HIGHEST_PRIORITY 2
#define LOWEST_PRIORITY 255

#define wind_normalized_prio(prio, sched_type)  \
  ({ int __p = sched_get_priority_min(sched_type) + ( ( ( LOWEST_PRIORITY -
(prio) ) * ( sched_get_priority_max(sched_type) - sched_get_priority_min
(sched_type) ) ) / LOWEST_PRIORITY ); __p; })

int main()
{
   mlockall(MCL_CURRENT | MCL_FUTURE);

   struct sched_param parA;
   parA.sched_priority = wind_normalized_prio(DEFAULT_PRIORITY,
SCHED_FIFO);
   pthread_t threadA;
   pthread_attr_t pthread_attrA;
   int res;

   res = pthread_attr_init(&pthread_attrA);
   res = pthread_attr_setinheritsched (&pthread_attrA,
PTHREAD_EXPLICIT_SCHED);
   res = pthread_attr_setschedpolicy (&pthread_attrA, SCHED_FIFO);
   res = pthread_attr_setschedparam( &pthread_attrA, &parA );
   res = pthread_create( &threadA, &pthread_attrA, bodyA, NULL );
#ifdef __XENO__
   pthread_set_name_np( threadA, "threadA" );
#endif
   res = pthread_attr_destroy( &pthread_attrA );



   struct sched_param parB;
   parB.sched_priority = wind_normalized_prio(DEFAULT_PRIORITY,
SCHED_FIFO);
   pthread_t threadB;
   pthread_attr_t pthread_attrB;

   res = pthread_attr_init(&pthread_attrB);
   res = pthread_attr_setinheritsched (&pthread_attrB,
PTHREAD_EXPLICIT_SCHED);
   res = pthread_attr_setschedpolicy (&pthread_attrB, SCHED_FIFO);
   pthread_attr_setschedparam( &pthread_attrB, &parB );
   res = pthread_create( &threadB, &pthread_attrB, bodyB, NULL );
#ifdef __XENO__
   pthread_set_name_np( threadB, "threadB" );
#endif
   res = pthread_attr_destroy( &pthread_attrB );


   pthread_cond_t cond;
   pthread_mutex_t mutex;
   pthread_mutexattr_t attr;

   res = pthread_mutexattr_init( &attr );
   res = pthread_mutexattr_setprotocol( &attr, PTHREAD_PRIO_INHERIT );
   res = pthread_mutex_init( &mutex, &attr );
   res = pthread_mutexattr_destroy( &attr );
   res = pthread_cond_init( &cond, NULL );

   bool state = false;
   res = pthread_mutex_lock( &mutex );
   while ( !state )
   {
      res = pthread_cond_wait( &cond, &mutex );
      if ( 0 != res )
      {
         res = pthread_mutex_unlock( &mutex );
         return -1;
      }
      else
      {
         (void)res;
      }
   }
   state = true;
   res = pthread_mutex_unlock( &mutex );

   return 0;
}

------------------------------------
Linux without gdb : Ok
------------------------------------

------------------------------------
Linux with gdb : Ok
------------------------------------
Thread [3] 5111 (Suspended : Container)
__kernel_vsyscall() at 0xb7fe1424
pthread_cond_wait@domain.hid()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:142
 0xb7fbd4ad
bodyB() at /home/generation/Projets/PosixTest/src/Main.cpp:55 0x8048af1
start_thread() at pthread_create.c:304 0xb7fb8cc9
clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130 0xb7e1469e

Thread [2] 5110 (Suspended : Container)
__kernel_vsyscall() at 0xb7fe1424
pthread_cond_wait@domain.hid()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:142
 0xb7fbd4ad
bodyA() at /home/generation/Projets/PosixTest/src/Main.cpp:21 0x8048a01
start_thread() at pthread_create.c:304 0xb7fb8cc9
clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130 0xb7e1469e

Thread [1] 5106 (Suspended : Signal : SIGINT:Interrupt)
__kernel_vsyscall() at 0xb7fe1424
pthread_cond_wait@domain.hid()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:142
 0xb7fbd4ad
main() at /home/generation/Projets/PosixTest/src/Main.cpp:131 0x8048dfa

------------------------------------
Xenomai without gdb : Ok
------------------------------------
generation@domain.hid$ cat /proc/xenomai/sched
CPU PID CLASS PRI TIMEOUT TIMEBASE STAT NAME
0 0 idle -1 - master R ROOT/0
1 0 idle -1 - master R ROOT/1
0 5025 rt 0 - master W PosixTest
0 5026 rt 60 - master W threadA
0 5027 rt 60 - master W threadB

------------------------------------
Xenomai with gdb : Nok
------------------------------------

->Step 1 : (break point on pthread_cond_wait)

Thread [2] 5193 (Suspended : Breakpoint)
bodyA() at /home/generation/Projets/PosixTest/src/Main.cpp:21 0x8048b0f
0xb7fc30b2
start_thread() at pthread_create.c:304 0xb7fa4cc9
clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130 0xb7df869e

Thread [1] 5188 (Suspended : Container)
__kernel_vsyscall() at 0xb7fe1424
mmap() at ../sysdeps/unix/sysv/linux/i386/mmap.S:62 0xb7df4a88
allocate_stack() at allocatestack.c:489 0xb7fa563b
__pthread_create_2_1() at pthread_create.c:458 0xb7fa563b
__real_pthread_create() at 0xb7fca382
__wrap_pthread_create() at 0xb7fc2e2f
main() at /home/generation/Projets/PosixTest/src/Main.cpp:110 0x8048e7e

->Step 2 : break point after pthread_cond_wait. pthread_cond_wait retrun 1
(EPERM)

Thread [3] 5204 (Suspended : Container)
__kernel_vsyscall() at 0xb7fe1424
__lll_lock_wait_private()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:95
0xb7fac133
_L_lock_2466() at 0xb7fa5d2a
start_thread() at pthread_create.c:295 0xb7fa4ec1
clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130 0xb7df869e

Thread [2] 5193 (Suspended : Step)
bodyA() at /home/generation/Projets/PosixTest/src/Main.cpp:22 0x8048b24
0xb7fc30b2
start_thread() at pthread_create.c:304 0xb7fa4cc9
clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130 0xb7df869e

Thread [1] 5188 (Suspended : Container)

[-- Attachment #2: Type: text/html, Size: 9214 bytes --]

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

> pthread_cond_wait (). it returns EPERM when the application is started with gdb.

I also stumbled over this

(see https://mail.gna.org/public/xenomai-help/2010-12/msg00080.html)

and so far have not found a solution. In my application, there's a tight loop
calling pthread_cond_wait and I have to issue usleep(100) in case of EPERM, to
avoid total lockup when running with gdbserver. It is absolutely no issue
without gdbserver though.

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
>> pthread_cond_wait (). it returns EPERM when the application is started with gdb.
> 
> I also stumbled over this
> 
> (see https://mail.gna.org/public/xenomai-help/2010-12/msg00080.html)
> 
> and so far have not found a solution. 

The issue is probably that pthread_cond_wait ends-up trying to relock
the mutex which is already locked while being restarted when handling
gdb signals. The way to debug this issue is simply to follow the path of
pthread_cond_wait when running under gdb, adding printks along the way.
This is far from being a problem for which no solution can be found.

Now, since I never got this issue, I assumed it must be specific to the
kernel or glibc you were using (you are using uclinux on blackfin with
linuxthreads, which is a very specific setup). We now have an other
occurrence of this issue, so it must be generic.

The thing is, I am unable to reproduce it. So, I am going to describe
the way I test this:

I launch cond-torture-posix inside gdb (gdbserver actually)
in gdb, type "handle SIG34 pass nostop noprint"
then "run"
And the program runs without troubles.

So, could you describe me exactly the procedure you are following wich
allows to reproduce this issue?


> In my application, there's a tight loop
> calling pthread_cond_wait and I have to issue usleep(100) in case of EPERM, to
> avoid total lockup when running with gdbserver. It is absolutely no issue
> without gdbserver though.

As already explained too, when a service returns an error, if you call
the same service again, you will get the same error, and if this service
is a primary mode service, you are guaranteed to lock-up, because you
essentially create an infinite loop in primary mode. If you fail to take
care of the errors returned by OS services, then your application is at
fault. In other words, the lockup is not due to the pthread_cond_wait
bug, it is due to your application bad coding style.

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

> So, could you describe me exactly the procedure you are following wich
> allows to reproduce this issue?


My attempt to run cond-torture-posix step by step:

1. copy cond-torture-posix as it was built in the blackfin-linux-dist (FDPIC) to target

/opt/uClinux/blackfin-linux-dist/user/xenomai/build-xenomai-2.5.5.2/src/testsuite/unit/.libs/cond-torture-posix

2. first attempt to start cond-torture-posix fails because librt.so.0 was not on my target, so I transferred /opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/librt.so.0

3. cond-torture-posix standalone passes

4. I start cond-torture-posix on the target with "gdbserver :2222 ./cond-torture-posix"

5. I start bfin-linux-uclibc-gdb and issue the commands

file cond-torture-posix
target remote 10.0.10.9:2222
break main
cont

6. The result is a SEGV on the target as described in https://mail.gna.org/public/xenomai-help/2010-12/msg00088.html  - even before breakpoint main() was reached and without backtrace in gdb.


/usr/bin # gdbserver :2222 ./cond-torture-posix 
Process ./cond-torture-posix created; pid = 240
Listening on port 2222
Remote debugging from host 10.0.10.10
NULL pointer access
Deferred Exception context
CURRENT PROCESS:
COMM=cond-torture-po PID=240  CPU=0
TEXT = 0x01738000-0x0173e214        DATA = 0x016e6214-0x016e6610
  BSS = 0x016e6610-0x016a0000  USER-STACK = 0x016bfe60

return address: [0x01726f10]; contents of:
0x01726ef0:  e42f  0015  0c07  1405  3047  67f8  e628  0015 
0x01726f00:  320e  3044  300d  3014  e50a  003a  5ea2  9153 
0x01726f10: [9159] ac5b  0061  0c07  1404  6000  e628  0015 
0x01726f20:  e801  0000  05a4  0010  e51a  0016  05f4  e800

ADSP-BF537-0.3 533(MHz CCLK) 133(MHz SCLK) (mpu off)
Linux version 2.6.34.7-ADI-2010R1-svn10663 (kawk@domain.hid) (gcc version 4.3.5 (ADI-2010R1-RC4) ) #33 Wed Jan 12 10:02:14 CET 2011

SEQUENCER STATUS:		Not tainted
  SEQSTAT: 00060027  IPEND: 0008  IMASK: ffff  SYSCFG: 0006
   EXCAUSE   : 0x27
   physical IVG3 asserted : <0xffa0076c> { _trap + 0x0 }
  RETE: <0x00000000> /* Maybe null pointer? */ RETN: <0x0161e000> /* kernel
dynamic memory */
  RETX: <0x00000480> /* Maybe fixed code section */
  RETS: <0x01726eda> [ /lib/libpthread.so.0 + 0x6eda ]
  PC  : <0x01726f10> [ /lib/libpthread.so.0 + 0x6f10 ]
DCPLB_FAULT_ADDR: <0x00000000> /* Maybe null pointer? */
...





What I'm actually doing to reproduce the EPERM from pthread_cond_wait in a 
situation where I think it shouldn't occur was with the code I posted. Or,
keeping printfs() etc away from the tasks in which the pthread_cond_wait is
used, the code following at the end might be better suited to serve as an example.

I'd be interested if this example gives the same output on Pierre Quelin's system?


Explanation first - the core loop of each of three threads in the
example is as follows. It just sets bits in an errbits[] variable for each
thread depending on the result of pthread_cond_wait. The main task sleeps a
second, then sets run==0 and broadcasts on cond to stop all threads.


    pthread_mutex_lock(&mutex);
    while (run)
    {
        int r = pthread_cond_wait(&cond, &mutex);
        loopcount[tnum]++;
        switch(r)
        {
            case 0:  errbits[tnum] |= LOG_NOERR; break;
            case 1:  errbits[tnum] |= LOG_EPERM; pthread_yield(); break;
            default: errbits[tnum] |= LOG_OTHER; pthread_yield(); break;
        }
    }
    pthread_mutex_unlock(&mutex);



Not sure if the pthread_yield() was necessary in this version of the code, it
might be a remainder of further experiments with varying priorities for the
threads.


I compile it with

bfin-linux-uclibc-gcc \
   -I/opt/uClinux/blackfin-linux-dist/staging/usr/include \
   -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib \
   -g -fPIC -fmessage-length=0 -mfast-fp -D_GNU_SOURCE -D_REENTRANT \
   -D__XENO__ -Wl,@/opt/uClinux/blackfin-linux-dist/staging/usr/lib/posix.wrappers \
   -lpthread_rt -lxenomai -o try try.c

Then transfer it to the target and run it standalone - the result is

# ./try 
0 1x 0x0010
1 1x 0x0010
2 1x 0x0010

This result means that the loop body in each of three tasks was executed exactly
once and the result of pthread_cond_wait in the loop body was (always) zero (=>
the errbits are set to 0x0010, LOG_NOERR).


In contrast, I tried to run it via gdbserver. The commands were

set verbose on
set solib-absolute-prefix notexistent
set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
file try
target remote 10.0.10.9:2222
break main
cont
cont



The result on the target is now

/tmp # gdbserver :2222 ./try
Process ./try created; pid = 281
Listening on port 2222
Remote debugging from host 10.0.10.10
0 3784x 0x0001
1 6686x 0x0001
2 1x 0x0010


The 0x0001 (LOG_EPERM) shown for the first two threads means they always got
EPERM, never success.


By chance, I found that my example succeeds in all three threads (as without
gdbserver) on the target if I omit loading symbols with the "file" command in
gdb and just issue "target remote 10.0.10.9:2222" and "cont".


Here's the full code:



/* 2010-12-27 - test program for pthread_cond_wait */

#include <stdio.h>
#include <string.h>
#include <posix/pthread.h>

#define NUM_THREADS 3

#define LOG_EPERM 0x0001
#define LOG_OTHER 0x0008
#define LOG_NOERR 0x0010

volatile int run;
volatile unsigned errbits[NUM_THREADS];
volatile unsigned loopcount[NUM_THREADS];
pthread_cond_t cond;
pthread_mutex_t mutex;
const struct timespec dt = { 0, 100*1000 };

void* test_thread(void *cookie)
{
     int tnum = *(int*)cookie;

     pthread_mutex_lock(&mutex);
     while (run)
     {
         int r = pthread_cond_wait(&cond, &mutex);
         loopcount[tnum]++;
         switch(r)
         {
             case 0:  errbits[tnum] |= LOG_NOERR; break;
             case 1:  errbits[tnum] |= LOG_EPERM; pthread_yield(); break;
             default: errbits[tnum] |= LOG_OTHER; pthread_yield(); break;
         }
     }
     pthread_mutex_unlock(&mutex);

     return NULL;
}

int main (void)
{
     int r;
     int i;
     int tnum[NUM_THREADS];
     pthread_t tid[NUM_THREADS];

     run = 1;
     r = pthread_cond_init(&cond, NULL); if (r!=0) printf("cond_init: %d\n", r);
     r = pthread_mutex_init(&mutex, NULL); if (r!=0) printf("mutex_init: %d\n", r);

     pthread_attr_t attr;
     r = pthread_attr_init(&attr);
     if (r!=0) printf("attr_init: %d\n", r);

     for (i=0; i<NUM_THREADS; i++)
     {
         tnum[i] = i;
         errbits[i] = 0;
         loopcount[i] = 0;
         r = pthread_create(&(tid[i]), &attr, test_thread, &(tnum[i]));
         if (r!=0) printf("create[%d]: %d\n", i, r);
     }

     sleep(1);

     run = 0;
     r = pthread_cond_broadcast(&cond);
     if (r!=0) printf("cond_broadcast: %d\n", r);

     for (i=0; i<NUM_THREADS; i++)
     {
         void *rp;
         r = pthread_join(tid[i], &rp);
         if (r!=0) printf("join[%d]: %d\n", i, r);
     }

     for (i=0; i<NUM_THREADS; i++)
     {
         printf("%d %dx 0x%04X\n", i, loopcount[i], errbits[i]);
     }

     return r;
}




Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
>> So, could you describe me exactly the procedure you are following wich
>> allows to reproduce this issue?
> 
> 
> My attempt to run cond-torture-posix step by step:
> 
> 1. copy cond-torture-posix as it was built in the blackfin-linux-dist (FDPIC) to target
> 
> /opt/uClinux/blackfin-linux-dist/user/xenomai/build-xenomai-2.5.5.2/src/testsuite/unit/.libs/cond-torture-posix
> 
> 2. first attempt to start cond-torture-posix fails because librt.so.0 was not on my target, so I transferred /opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib/librt.so.0
> 
> 3. cond-torture-posix standalone passes
> 
> 4. I start cond-torture-posix on the target with "gdbserver :2222 ./cond-torture-posix"
> 
> 5. I start bfin-linux-uclibc-gdb and issue the commands
> 
> file cond-torture-posix
> target remote 10.0.10.9:2222
> break main
> cont

Ok. On my side: I call set solib-absolute-prefix to where the debug
binaries for the target filesystem are. And I call
handle SIG34 nostop noprint pass.

Coud you try and do the same?


-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

>> file cond-torture-posix
>
> Ok. On my side: I call set solib-absolute-prefix to where the debug
> binaries for the target filesystem are. And I call
> handle SIG34 nostop noprint pass.
>
> Coud you try and do the same?

Is SIG34 the same on blackfin? I do not remember ever having seen SIG34, only
SIG32 ("Real-time event 32")

Independent of that, the result is always the same SEGV. I cannot use the absolute-prefix currently, as the directory layout is different on the target. So my script is now

set solib-absolute-prefix notexistent
set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
file cond-torture-posix
handle SIG34 nostop noprint pass
target remote 10.0.10.9:2222

And regardless whether I add an "break main", the SEGV will occur immediately after telling gdb to "cont".

Does my "try.c" always succeed (all errbits=0x0010) in your environment?


Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
>>> file cond-torture-posix
>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>> binaries for the target filesystem are. And I call
>> handle SIG34 nostop noprint pass.
>>
>> Coud you try and do the same?
> 
> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34, only
> SIG32 ("Real-time event 32")
> 
> Independent of that, the result is always the same SEGV. I cannot use the absolute-prefix currently, as the directory layout is different on the target. So my script is now

Ok. I tried cond-torture-posix without set-solib-absolute prefix, or
without handle SIG34, added the "break main". Everything runs fine.

So, I am afraid you are on you own if you want to debug this.

> 
> set solib-absolute-prefix notexistent
> set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
> file cond-torture-posix
> handle SIG34 nostop noprint pass
> target remote 10.0.10.9:2222
> 
> And regardless whether I add an "break main", the SEGV will occur immediately after telling gdb to "cont".
> 
> Does my "try.c" always succeed (all errbits=0x0010) in your environment?

I was reluctant to try, because for me cond-torture-posix should be the
reference, and the program is bogus in the way it handles
pthread_cond_wait errors, as I already explained, and may have bugs
which may escape at first sight (for instance, there is a race with the
sleep(1) and the time it takes to start the threads, which may well byte
you when running under gdb). Anyway, I tried, and it works like a charm,
however it appears to me now that you are clearly mis-compiling this
program, since you should be using #include <pthread.h>, instead of
#include <posix/pthread.h>, and more importantly, this program is
missing a call to mlockall without which it can not possibly run under
Xenomai.

So, to settle the matters, could you post here the result of
"bfin-linux-uclibc-nm -s try".
?

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Waschk,Kolja]

Hi,

> reference, and the program is bogus in the way it handles
> pthread_cond_wait errors, as I already explained,

You're certainly right with that. It's just that I have to deal with foreign
code that contains exactly such tight loops with pthread_cond_wait as its
only brake, and this code I'd like to use unmodified, as far as possible. Now
the test code try.c started as a clone of the original, so it has the same
obvious shortcomings.

> missing a call to mlockall without which it can not possibly run under
> Xenomai.

Oh, you're right (but it's present in the original code)

> program, since you should be using #include <pthread.h>, instead of
> #include <posix/pthread.h>, and more importantly, this program is

Yes. That's an artefact of another problem which seems more toolchain-related
in my case. Already noted in our issue tracking system. However, I tried to
verify that everything is wrapped and linked as supposed;

> So, to settle the matters, could you post here the result of
> "bfin-linux-uclibc-nm -s try".
> ?

The result is

00002158 A ___bss_start
00002158 b _completed.4861
000021ac B _cond
00001f78 d ___CTOR_END__
00001f74 d ___CTOR_LIST__
          w ___deregister_frame_info@domain.hid
00000e5c t ___do_global_ctors_aux
00000a58 t ___do_global_dtors_aux
00002068 D ___dso_handle
00000ea0 R _dt
00001f80 d ___DTOR_END__
0000215c b _dtor_idx.4863
00001f7c d ___DTOR_LIST__
00001f88 d _DYNAMIC
00002158 A __edata
00000f70 r ___EH_FRAME_BEGIN__
000021b8 A __end
00002184 B _errbits
          U ___errno_location
00000e8c T __fini
00000ac4 t _frame_dummy
00000f70 r ___FRAME_END__
000020e0 d __GLOBAL_OFFSET_TABLE_
00000780 T __init
00001f84 d ___JCR_END__
00001f84 d ___JCR_LIST__
          w __Jv_RegisterClasses
00002178 B _loopcount
00000c7c T _main
00002190 B _mutex
00002160 b _object.4883
          U _printf
00000b0c W _pthread_atfork
          U _pthread_attr_init
          U _pthread_join
          w ___register_frame_info@domain.hid
00000f70 R __ROFIXUP_END__
00000f1c R __ROFIXUP_LIST__
000021a8 B _run
000008ec t ___self_reloc
00000b20 W _shm_open
00000b3c W _shm_unlink
          U _sleep
00020000 A __stacksize
00000888 T __start
00000b54 T _test_thread
          U ___uClibc_main
          U ___wrap_pthread_cond_broadcast
          U ___wrap_pthread_cond_init
          U ___wrap_pthread_cond_wait
          U ___wrap_pthread_create
          U ___wrap_pthread_mutex_init
          U ___wrap_pthread_mutex_lock
          U ___wrap_pthread_mutex_unlock
          U ___wrap_pthread_yield


-- 
mr. kolja waschk - haubach-39 - 22765 hh - germany
fon +49 40 889130-34 - fax -35 - http://www.ixo.de

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Waschk,Kolja wrote:
> Hi,
> 
>> reference, and the program is bogus in the way it handles
>> pthread_cond_wait errors, as I already explained,
> 
> You're certainly right with that. It's just that I have to deal with foreign
> code that contains exactly such tight loops with pthread_cond_wait as its
> only brake, and this code I'd like to use unmodified, as far as possible. Now
> the test code try.c started as a clone of the original, so it has the same
> obvious shortcomings.
> 
>> missing a call to mlockall without which it can not possibly run under
>> Xenomai.
> 
> Oh, you're right (but it's present in the original code)

Ok. mlockall may not be needed on uclinux after all.

> 
>> program, since you should be using #include <pthread.h>, instead of
>> #include <posix/pthread.h>, and more importantly, this program is
> 
> Yes. That's an artefact of another problem which seems more toolchain-related
> in my case. Already noted in our issue tracking system. However, I tried to
> verify that everything is wrapped and linked as supposed;

As reminder, the correct way to compile a xenomai posix skin program is
described here:
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.

> 
>> So, to settle the matters, could you post here the result of
>> "bfin-linux-uclibc-nm -s try".
>> ?
> 
> The result is
> 
> 00002158 A ___bss_start
> 00002158 b _completed.4861
> 000021ac B _cond
> 00001f78 d ___CTOR_END__
> 00001f74 d ___CTOR_LIST__
>           w ___deregister_frame_info@domain.hid
> 00000e5c t ___do_global_ctors_aux
> 00000a58 t ___do_global_dtors_aux
> 00002068 D ___dso_handle
> 00000ea0 R _dt
> 00001f80 d ___DTOR_END__
> 0000215c b _dtor_idx.4863
> 00001f7c d ___DTOR_LIST__
> 00001f88 d _DYNAMIC
> 00002158 A __edata
> 00000f70 r ___EH_FRAME_BEGIN__
> 000021b8 A __end
> 00002184 B _errbits
>           U ___errno_location
> 00000e8c T __fini
> 00000ac4 t _frame_dummy
> 00000f70 r ___FRAME_END__
> 000020e0 d __GLOBAL_OFFSET_TABLE_
> 00000780 T __init
> 00001f84 d ___JCR_END__
> 00001f84 d ___JCR_LIST__
>           w __Jv_RegisterClasses
> 00002178 B _loopcount
> 00000c7c T _main
> 00002190 B _mutex
> 00002160 b _object.4883
>           U _printf
> 00000b0c W _pthread_atfork
>           U _pthread_attr_init
>           U _pthread_join
>           w ___register_frame_info@domain.hid
> 00000f70 R __ROFIXUP_END__
> 00000f1c R __ROFIXUP_LIST__
> 000021a8 B _run
> 000008ec t ___self_reloc
> 00000b20 W _shm_open
> 00000b3c W _shm_unlink
>           U _sleep
> 00020000 A __stacksize
> 00000888 T __start
> 00000b54 T _test_thread
>           U ___uClibc_main
>           U ___wrap_pthread_cond_broadcast
>           U ___wrap_pthread_cond_init
>           U ___wrap_pthread_cond_wait
>           U ___wrap_pthread_create
>           U ___wrap_pthread_mutex_init
>           U ___wrap_pthread_mutex_lock
>           U ___wrap_pthread_mutex_unlock
>           U ___wrap_pthread_yield
> 
> 

you sure this is the "try" program for which you sent the sources? I do
not understand the references to shm_open, shm_unlink, for instance.


-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Waschk,Kolja]

Hi,

> you sure this is the "try" program for which you sent the sources? I do

Yes.

> not understand the references to shm_open, shm_unlink, for instance.

Somewhat strange, indeed. From the longer output of objdump -D, I conclude that
shm_open and shm_unlink code (a few assembly words) is contained in the binary,
but not called from anywhere in the remaining code within "try".

Kolja


-- 
mr. kolja waschk - haubach-39 - 22765 hh - germany
fon +49 40 889130-34 - fax -35 - http://www.ixo.de

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1916 bytes --]

>>> program, since you should be using #include <pthread.h>, instead of
>>> #include <posix/pthread.h>, and more importantly, this program is
>>
>> Yes. That's an artefact of another problem which seems more toolchain-related
>> in my case. Already noted in our issue tracking system. However, I tried to
>
> As reminder, the correct way to compile a xenomai posix skin program is
> described here:
> http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.


It is impossible for me to use -I$(PREFIX)/include/posix so that I could simply
#include <pthread.h> when using bfin-linux-uclibc-g++(!). The result whenever I
just try to do something like #include <stdio.h> would be the following. It
does work when using gcc instead of g++ (but that's obviously no option for C++
code)


a.c: #include <stdio.h>

bfin-linux-uclibc-g++ -D_GNU_SOURCE -D_REENTRANT -D__XENO__ \
     -I$PREFIX/usr/include -I$PREFIX/usr/include/posix -c a.c


In file included from /opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/thread.h:25,
                  from /opt/uClinux/blackfin-linux-dist/staging/usr/include/posix/pthread.h:136,
                  from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/bits/uClibc_mutex.h:15,
                  from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/bits/uClibc_stdio.h:107,
                  from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/stdio.h:72,
                  from a.c:1:
/opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/types.h: In function ‘void xnobject_copy_name(char*, const char*)’:
/opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/types.h:113: error: ‘snprintf’ was not declared in this scope

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Philippe Gerum]

On Fri, 2011-01-21 at 14:09 +0100, Kolja Waschk wrote:
> >>> program, since you should be using #include <pthread.h>, instead of
> >>> #include <posix/pthread.h>, and more importantly, this program is
> >>
> >> Yes. That's an artefact of another problem which seems more toolchain-related
> >> in my case. Already noted in our issue tracking system. However, I tried to
> >
> > As reminder, the correct way to compile a xenomai posix skin program is
> > described here:
> > http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.
> 
> 
> It is impossible for me to use -I$(PREFIX)/include/posix so that I could simply
> #include <pthread.h> when using bfin-linux-uclibc-g++(!). The result whenever I
> just try to do something like #include <stdio.h> would be the following. It
> does work when using gcc instead of g++ (but that's obviously no option for C++
> code)
> 
> 
> a.c: #include <stdio.h>
> 
> bfin-linux-uclibc-g++ -D_GNU_SOURCE -D_REENTRANT -D__XENO__ \
>      -I$PREFIX/usr/include -I$PREFIX/usr/include/posix -c a.c
> 
> 
> In file included from /opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/thread.h:25,
>                   from /opt/uClinux/blackfin-linux-dist/staging/usr/include/posix/pthread.h:136,
>                   from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/bits/uClibc_mutex.h:15,
>                   from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/bits/uClibc_stdio.h:107,
>                   from /opt/uClinux-2010R1-RC5_tools-RC4/bfin-linux-uclibc/bin/../bfin-linux-uclibc/runtime/usr/include/stdio.h:72,
>                   from a.c:1:
> /opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/types.h: In function ‘void xnobject_copy_name(char*, const char*)’:
> /opt/uClinux/blackfin-linux-dist/staging/usr/include/nucleus/types.h:113: error: ‘snprintf’ was not declared in this scope
> 

diff --git a/include/nucleus/types.h b/include/nucleus/types.h
index f49131c..28726df 100644
--- a/include/nucleus/types.h
+++ b/include/nucleus/types.h
@@ -29,6 +29,7 @@
 #endif /* !CONFIG_PREEMPT_RT */
 #else /* !__KERNEL__ */
 #include <stdio.h>
+#include <string.h>
 #include <sys/types.h>
 #include <errno.h>
 #ifndef BITS_PER_LONG
@@ -107,16 +108,14 @@ typedef atomic_flags_t xnflags_t;
 
 #define XNOBJECT_NAME_LEN 32
 
-static inline void xnobject_copy_name(char *dst, const char *src)
-{
-    if (src)
-	snprintf(dst, XNOBJECT_NAME_LEN, "%s", src);
-    else
-        *dst = '\0';
-}
+#define xnobject_copy_name(dst, src)					\
+	do {								\
+		strncpy((dst), (src) ?: "", XNOBJECT_NAME_LEN-1)	\
+			[XNOBJECT_NAME_LEN-1] = '\0';			\
+	} while (0)
 
-#define xnobject_create_name(dst, n, obj) \
-    snprintf(dst, n, "%p", obj)
+#define xnobject_create_name(dst, n, obj)	\
+	snprintf(dst, n, "%p", obj)
 
 #define minval(a,b) ((a) < (b) ? (a) : (b))
 #define maxval(a,b) ((a) > (b) ? (a) : (b))

> 
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

>> Independent of that, the result is always the same SEGV. 
..
> So, I am afraid you are on you own if you want to debug this.

It seems that's completely unrelated. The SEGV always occurs if I compile my
application with -lpthread explicitly listed in the ldflags, as xeno-config
suggests. Maybe a toolchain problem, I'll ask there first

http://blackfin.uclinux.org/gf/forummessage/97601

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
>>> Independent of that, the result is always the same SEGV. 
> ..
>> So, I am afraid you are on you own if you want to debug this.
> 
> It seems that's completely unrelated. The SEGV always occurs if I compile my
> application with -lpthread explicitly listed in the ldflags, as xeno-config
> suggests. Maybe a toolchain problem, I'll ask there first
> 
> http://blackfin.uclinux.org/gf/forummessage/97601

The thing I do not understand is that you should not pass any ldflags to
cond-torture-posix, Xenomai build system should have been taken care
about this.

Anyway, are you using libpthread as a static library?

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

> The thing I do not understand is that you should not pass any ldflags to
> cond-torture-posix, Xenomai build system should have been taken care

I have to admit I haven't watched how cond-torture-posix was built. The one I
used then was built during the build process of blackfin-uclinux-dist. But
since it is the same error that occurs in my shortened example, and xeno-config
emits those flags, I assumed that compile flags were used for
cond-torture-posix similarly.

The short example I refer to is the one described in my posting to the 
blackfin toolchain-help Forum: Given the example code "a.c"

int main()
{
     return 0;
}

Compile it with:

bfin-linux-uclibc-gcc  -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lxenomai -lpthread_rt -lpthread a.c

And then load it on a BF537-STAMP via gdbserver. As soon as it is started with
gdb from the development host, the gdbserver/a.out process will terminate with
NULL pointer access exception. Even before main() is reached...  The SEGV doesn't
occur if -lpthread is omitted.

More details: http://blackfin.uclinux.org/gf/forummessage/97601

If you think this is really Xenomai-related, I think we should start a separate thread for it
here or at least change the subject

> Anyway, are you using libpthread as a static library?

No, all shared.

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
>> The thing I do not understand is that you should not pass any ldflags to
>> cond-torture-posix, Xenomai build system should have been taken care
> 
> I have to admit I haven't watched how cond-torture-posix was built. The one I
> used then was built during the build process of blackfin-uclinux-dist. But
> since it is the same error that occurs in my shortened example, and xeno-config
> emits those flags, I assumed that compile flags were used for
> cond-torture-posix similarly.
> 
> The short example I refer to is the one described in my posting to the 
> blackfin toolchain-help Forum: Given the example code "a.c"
> 
> int main()
> {
>      return 0;
> }
> 
> Compile it with:
> 
> bfin-linux-uclibc-gcc  -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lxenomai -lpthread_rt -lpthread a.c

The link order is wrong. It should be -lpthread_rt -lxenomai -lpthread.

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Kolja Waschk wrote:
>> Hi,
>>
>>> The thing I do not understand is that you should not pass any ldflags to
>>> cond-torture-posix, Xenomai build system should have been taken care
>> I have to admit I haven't watched how cond-torture-posix was built. The one I
>> used then was built during the build process of blackfin-uclinux-dist. But
>> since it is the same error that occurs in my shortened example, and xeno-config
>> emits those flags, I assumed that compile flags were used for
>> cond-torture-posix similarly.
>>
>> The short example I refer to is the one described in my posting to the 
>> blackfin toolchain-help Forum: Given the example code "a.c"
>>
>> int main()
>> {
>>      return 0;
>> }
>>
>> Compile it with:
>>
>> bfin-linux-uclibc-gcc  -L/opt/uClinux/blackfin-linux-dist/staging/usr/lib -lxenomai -lpthread_rt -lpthread a.c
> 
> The link order is wrong. It should be -lpthread_rt -lxenomai -lpthread.

Actually -lpthread_rt -lxenomai -lpthread -lrt.

Yes, please start a neew thread.


-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

> The link order is wrong. It should be -lpthread_rt -lxenomai -lpthread.

Okay, thanks, fixing that doesn't prevent the SEGV though.

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
>>> file cond-torture-posix
>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>> binaries for the target filesystem are. And I call
>> handle SIG34 nostop noprint pass.
>>
>> Coud you try and do the same?
> 
> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34, only
> SIG32 ("Real-time event 32")
> 
> Independent of that, the result is always the same SEGV. I cannot use the absolute-prefix currently, as the directory layout is different on the target. So my script is now
> 
> set solib-absolute-prefix notexistent
> set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
> file cond-torture-posix
> handle SIG34 nostop noprint pass
> target remote 10.0.10.9:2222
> 
> And regardless whether I add an "break main", the SEGV will occur immediately after telling gdb to "cont".
> 
> Does my "try.c" always succeed (all errbits=0x0010) in your environment?

Ok, I get the failure if I set up a breakpoint right after the call to
pthread_cond_wait, as noted by Pierre. After some debugging, it appears
that the syscall is restarted whereas it should return to user-spacce
and let the user-space skin do its job. So, it seems that somehow, the
behaviour is different for gdb signals than for usual signals.

Working on it now, will tell you when we have a status.

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Kolja Waschk wrote:
>>>> file cond-torture-posix
>>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>>> binaries for the target filesystem are. And I call
>>> handle SIG34 nostop noprint pass.
>>>
>>> Coud you try and do the same?
>> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34, only
>> SIG32 ("Real-time event 32")
>>
>> Independent of that, the result is always the same SEGV. I cannot use the absolute-prefix currently, as the directory layout is different on the target. So my script is now
>>
>> set solib-absolute-prefix notexistent
>> set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
>> file cond-torture-posix
>> handle SIG34 nostop noprint pass
>> target remote 10.0.10.9:2222
>>
>> And regardless whether I add an "break main", the SEGV will occur immediately after telling gdb to "cont".
>>
>> Does my "try.c" always succeed (all errbits=0x0010) in your environment?
> 
> Ok, I get the failure if I set up a breakpoint right after the call to
> pthread_cond_wait, as noted by Pierre. After some debugging, it appears
> that the syscall is restarted whereas it should return to user-spacce
> and let the user-space skin do its job. So, it seems that somehow, the
> behaviour is different for gdb signals than for usual signals.
> 
> Working on it now, will tell you when we have a status.

The following patch seems to fix the issue, but I am not yet sure 
whether it is really correct:

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index d27494c..717a8a0 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -770,7 +770,7 @@ static inline void request_syscall_restart(xnthread_t *thread,
 		if (__xn_interrupted_p(regs)) {
 			__xn_error_return(regs,
 					  (sysflags & __xn_exec_norestart) ?
-					  -ERESTARTNOHAND : -ERESTARTSYS);
+					  -EINTR : -ERESTARTSYS);
 			notify = !xnthread_test_state(thread, XNDEBUG);
 		}
 


-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

> The following patch seems to fix the issue, but I am not yet sure
> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c

Yes it does fix it for me too. The output of my "try" program when run with
gdbserver still differs from the output when run standalone, but at least there
are no EPERM results anymore. The first two tasks cycle pthread_cond_wait more
than once.

0 3x 0x0010
1 2x 0x0010
2 1x 0x0010

If I remove the pthread_yield() again there'll be a lockup again, for which I
cannot see an actual reason. Now, there's no need to explain why this code
can enter an endless loop and that it's no good style to do nothing with error
return codes. But.. shouldn't I be able to break in with gdb via gdbserver
anyway and see where the application is stuck? To interrupt - by chance - the
loop in the right moment to be able a look at my result variable "r"...  Even
if the loop is in a RT task with highest priority?

According to
http://www.xenomai.org/index.php/FAQs#How_can_GDB_be_used.3F
there are no limitations. Maybe it is specific to uClinux/linuxthreads/...?

I was originally expecting that I could hit Ctrl-C on the gdb host at any
moment, type "info threads" and get an idea of what is happening in my stuck
app (taking into account that afterwards some threads might have left their
domain just because I interacted).

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Philippe Gerum]

On Fri, 2011-01-21 at 13:03 +0100, Kolja Waschk wrote:
> Hi,
> 
> > The following patch seems to fix the issue, but I am not yet sure
> > diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> 
> Yes it does fix it for me too. The output of my "try" program when run with
> gdbserver still differs from the output when run standalone, but at least there
> are no EPERM results anymore. The first two tasks cycle pthread_cond_wait more
> than once.
> 
> 0 3x 0x0010
> 1 2x 0x0010
> 2 1x 0x0010
> 
> If I remove the pthread_yield() again there'll be a lockup again, for which I
> cannot see an actual reason. Now, there's no need to explain why this code
> can enter an endless loop and that it's no good style to do nothing with error
> return codes. But.. shouldn't I be able to break in with gdb via gdbserver
> anyway and see where the application is stuck? To interrupt - by chance - the
> loop in the right moment to be able a look at my result variable "r"...  Even
> if the loop is in a RT task with highest priority?
> 
> According to
> http://www.xenomai.org/index.php/FAQs#How_can_GDB_be_used.3F
> there are no limitations. Maybe it is specific to uClinux/linuxthreads/...?

This doc only says that GDB can be used the usual way, but it does not
guarantee that GDB may respond properly in case your real-time system
prevents the linux kernel from running.

> 
> I was originally expecting that I could hit Ctrl-C on the gdb host at any
> moment, type "info threads" and get an idea of what is happening in my stuck
> app (taking into account that afterwards some threads might have left their
> domain just because I interacted).

There is no way this could work if your target is stuck in an endless
primary mode loop. In that case, the gdb stub which is part of the
regular kernel just can't receive the remote "break" command packet sent
from your host, simply because the remote linux  kernel is not given any
CPU time. You have to enable the Xenomai watchdog for exiting this
situation.

I suspect that if pthread_yield() allows you to regain control via ^C,
then it is likely not the Xenomai wrapped service which gets called, but
rather the plain glibc one, which moves your thread to secondary mode,
hence resumes the linux kernel for a while, enough to process the
interrupt packet.

> 
> Kolja
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Kolja Waschk]

Hi,

> primary mode loop. In that case, the gdb stub which is part of the
> regular kernel just can't receive the remote "break" command packet sent
> from your host, simply because the remote linux  kernel is not given any
> CPU time.

Thanks for the clarification. I suspected so but the FAQ entry gave me some
hope that I might have been wrong ;) Are there any gdb macros that might help
to gather helpful information about tasks etc. with a debugger on a host
attached to the target via JTAG?

Kolja

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
>> The following patch seems to fix the issue, but I am not yet sure
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> 
> Yes it does fix it for me too. The output of my "try" program when run with
> gdbserver still differs from the output when run standalone, but at least there
> are no EPERM results anymore. The first two tasks cycle pthread_cond_wait more
> than once.

Ok. If pthread_cond_wait returns anything else than 0, could not you
simply print it then call exit?

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
>> The following patch seems to fix the issue, but I am not yet sure
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> 
> Yes it does fix it for me too. The output of my "try" program when run with
> gdbserver still differs from the output when run standalone, but at least there
> are no EPERM results anymore. The first two tasks cycle pthread_cond_wait more
> than once.
> 
> 0 3x 0x0010
> 1 2x 0x0010
> 2 1x 0x0010

Actually, that is normal, what you see are "spurious wake-ups" caused by
the signals sent by gdb, these are allowed by the posix specification.
However calling pthread_cond_wait again should not return immediately,
it should block until the call to pthread_cond_broadcast, so there
should not be a lockup.

-- 
                                                                Gilles.

[Xenomai-help] gpio

[Cagnulein]

I ported a linux environment module implementing gpio handling to
Xenomai environment.
Under linux i was able to see /dev/gpio1 and execute echo 1>  /dev/gpio1
command via bash shell to set the gpio output state.
Now, under Xenomai, with the RTDM driver developed and loaded I am not
able to get the gpio1 device.
Could you help me ?
Thanks
Roberto Viola

Re: [Xenomai-help] gpio

[Gilles Chanteperdrix]

Cagnulein wrote:
> I ported a linux environment module implementing gpio handling to
> Xenomai environment.
> Under linux i was able to see /dev/gpio1 and execute echo 1>  /dev/gpio1
> command via bash shell to set the gpio output state.
> Now, under Xenomai, with the RTDM driver developed and loaded I am not
> able to get the gpio1 device.
> Could you help me ?

The fact is that the system services you use to access a RTDM devices
are special services handled by Xenomai RTM skin, they are not usual
Linux services. So, there is no way you can access an RTDM device node
with Linux system calls (which is what echo 1 > /dev/gpio1 does).

Please avoid replying a random thread to post your question, as it
messes up those of us who order mails by threads, and notably the
mailing list archives.

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Pierre.QUELIN]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]



> Kolja Waschk wrote:
>>>> file cond-torture-posix
>>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>>> binaries for the target filesystem are. And I call
>>> handle SIG34 nostop noprint pass.
>>>
>>> Coud you try and do the same?
>> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34,
only
>> SIG32 ("Real-time event 32")
>>
>> Independent of that, the result is always the same SEGV. I cannot use
the absolute-prefix currently, as the directory layout is different on the
target. So my script is now
>>
>> set solib-absolute-prefix notexistent
>> set
solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib

>> file cond-torture-posix
>> handle SIG34 nostop noprint pass
>> target remote 10.0.10.9:2222
>>
>> And regardless whether I add an "break main", the SEGV will occur
immediately after telling gdb to "cont".
>>
>> Does my "try.c" always succeed (all errbits=0x0010) in your environment?
>
> Ok, I get the failure if I set up a breakpoint right after the call to
> pthread_cond_wait, as noted by Pierre. After some debugging, it appears
> that the syscall is restarted whereas it should return to user-spacce
> and let the user-space skin do its job. So, it seems that somehow, the
> behaviour is different for gdb signals than for usual signals.
>
> Working on it now, will tell you when we have a status.

The following patch seems to fix the issue, but I am not yet sure
whether it is really correct:

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index d27494c..717a8a0 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -770,7 +770,7 @@ static inline void request_syscall_restart(xnthread_t
*thread,
                         if (__xn_interrupted_p(regs)) {
                                     __xn_error_return(regs,
                                                               (sysflags &
__xn_exec_norestart) ?
-
-ERESTARTNOHAND : -ERESTARTSYS);
+                                                              -EINTR :
-ERESTARTSYS);
                                     notify = !xnthread_test_state(thread,
XNDEBUG);
                         }



--
                                                                Gilles.

Sorry but I'm a novice.

As I understand, your patch is a kernel patch and I need to rebuild the
kernel package.
Where can I find the cond-torture-posix application to reproduce the
problem with your test case ?
My PC is a very standard one (Xeon dual core and my distro an Ubuntu 10.10
so I think it's very easy to reproduce the test case.
Do you know if there is a bug tracker where tickets are logged to be
informed when this point will be solved ?

Thank you for you help.

Pierre Quélin

[-- Attachment #2: Type: text/html, Size: 3717 bytes --]

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Gilles Chanteperdrix]

Pierre.QUELIN@solystic.com wrote:
> 
>> Kolja Waschk wrote:
>>>>> file cond-torture-posix
>>>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>>>> binaries for the target filesystem are. And I call
>>>> handle SIG34 nostop noprint pass.
>>>>
>>>> Coud you try and do the same?
>>> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34,
> only
>>> SIG32 ("Real-time event 32")
>>>
>>> Independent of that, the result is always the same SEGV. I cannot use
> the absolute-prefix currently, as the directory layout is different on the
> target. So my script is now
>>> set solib-absolute-prefix notexistent
>>> set
> solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
> 
>>> file cond-torture-posix
>>> handle SIG34 nostop noprint pass
>>> target remote 10.0.10.9:2222
>>>
>>> And regardless whether I add an "break main", the SEGV will occur
> immediately after telling gdb to "cont".
>>> Does my "try.c" always succeed (all errbits=0x0010) in your environment?
>> Ok, I get the failure if I set up a breakpoint right after the call to
>> pthread_cond_wait, as noted by Pierre. After some debugging, it appears
>> that the syscall is restarted whereas it should return to user-spacce
>> and let the user-space skin do its job. So, it seems that somehow, the
>> behaviour is different for gdb signals than for usual signals.
>>
>> Working on it now, will tell you when we have a status.
> 
> The following patch seems to fix the issue, but I am not yet sure
> whether it is really correct:
> 
> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> index d27494c..717a8a0 100644
> --- a/ksrc/nucleus/shadow.c
> +++ b/ksrc/nucleus/shadow.c
> @@ -770,7 +770,7 @@ static inline void request_syscall_restart(xnthread_t
> *thread,
>                          if (__xn_interrupted_p(regs)) {
>                                      __xn_error_return(regs,
>                                                                (sysflags &
> __xn_exec_norestart) ?
> -
> -ERESTARTNOHAND : -ERESTARTSYS);
> +                                                              -EINTR :
> -ERESTARTSYS);
>                                      notify = !xnthread_test_state(thread,
> XNDEBUG);
>                          }
> 
> 
> 
> --
>                                                                 Gilles.
> 
> Sorry but I'm a novice.
> 
> As I understand, your patch is a kernel patch and I need to rebuild the
> kernel package.

Yes.

> Where can I find the cond-torture-posix application to reproduce the
> problem with your test case ?

It is part of Xenomai installation.

> My PC is a very standard one (Xeon dual core and my distro an Ubuntu 10.10
> so I think it's very easy to reproduce the test case.
> Do you know if there is a bug tracker where tickets are logged to be
> informed when this point will be solved ?

No. We use the mailing list for this. From our point of view, however,
the point is solved.

Also note that I did not replied to you personally, only to the list,
because otherwise I receive spam from you.

-- 
                                                                Gilles.

Re: [Xenomai-help] debug posix skin - pthread_cond_wait return EPERM

[Pierre.QUELIN]

[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]



>Gilles Chanteperdrix wrote:
>
>Pierre.QUELIN@solystic.com wrote:
>>
>>> Kolja Waschk wrote:
>>>>>> file cond-torture-posix
>>>>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>>>>> binaries for the target filesystem are. And I call
>>>>> handle SIG34 nostop noprint pass.
>>>>>
>>>>> Coud you try and do the same?
>>>> Is SIG34 the same on blackfin? I do not remember ever having seen
SIG34,
>> only
>>>> SIG32 ("Real-time event 32")
>>>>
>>>> Independent of that, the result is always the same SEGV. I cannot use
>> the absolute-prefix currently, as the directory layout is different on
the
>> target. So my script is now
>>>> set solib-absolute-prefix notexistent
>>>> set
>>
solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
>>
>>>> file cond-torture-posix
>>>> handle SIG34 nostop noprint pass
>>>> target remote 10.0.10.9:2222
>>>>
>>>> And regardless whether I add an "break main", the SEGV will occur
>> immediately after telling gdb to "cont".
>>>> Does my "try.c" always succeed (all errbits=0x0010) in your
environment?
>>> Ok, I get the failure if I set up a breakpoint right after the call to
>>> pthread_cond_wait, as noted by Pierre. After some debugging, it appears
>>> that the syscall is restarted whereas it should return to user-spacce
>>> and let the user-space skin do its job. So, it seems that somehow, the
>>> behaviour is different for gdb signals than for usual signals.
>>>
>>> Working on it now, will tell you when we have a status.
>>
>> The following patch seems to fix the issue, but I am not yet sure
>> whether it is really correct:
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index d27494c..717a8a0 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -770,7 +770,7 @@ static inline void request_syscall_restart
(xnthread_t
>> *thread,
>>                          if (__xn_interrupted_p(regs)) {
>>                                      __xn_error_return(regs,
>>                                                                (sysflags
&
>> __xn_exec_norestart) ?
>> -
>> -ERESTARTNOHAND : -ERESTARTSYS);
>> +                                                              -EINTR :
>> -ERESTARTSYS);
>>                                      notify = !xnthread_test_state
(thread,
>> XNDEBUG);
>>                          }
>>
>>
>>
>> --
>>                                                                 Gilles.
>>
>> Sorry but I'm a novice.
>>
>> As I understand, your patch is a kernel patch and I need to rebuild the
>> kernel package.
>
>Yes.
>
>> Where can I find the cond-torture-posix application to reproduce the
>> problem with your test case ?
>
>It is part of Xenomai installation.
>
>> My PC is a very standard one (Xeon dual core and my distro an Ubuntu
10.10
>> so I think it's very easy to reproduce the test case.
>> Do you know if there is a bug tracker where tickets are logged to be
>> informed when this point will be solved ?
>
>No. We use the mailing list for this. From our point of view, however,
>the point is solved.

I have not done a lot of tests but it seems to work fine for me in my basic
test case.

Result :
      Thread [3] 2905 (Suspended : Container)
            __kernel_vsyscall() at 0xb7fe1424
            __wrap_pthread_cond_wait() at 0xb7fc4815
            __wrap_pthread_cond_wait() at 0xb7fc479e
            bodyB() at /home/generation/Projets/PosixTest/src/Main.cpp:55
0x8048c11
            0xb7fc30b2
            start_thread() at pthread_create.c:304 0xb7fa4cc9
            clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130
0xb7df869e
      Thread [2] 2904 (Suspended : Container)
            __kernel_vsyscall() at 0xb7fe1424
            __wrap_pthread_cond_wait() at 0xb7fc4815
            __wrap_pthread_cond_wait() at 0xb7fc479e
            bodyA() at /home/generation/Projets/PosixTest/src/Main.cpp:21
0x8048b21
            0xb7fc30b2
            start_thread() at pthread_create.c:304 0xb7fa4cc9
            clone() at ../sysdeps/unix/sysv/linux/i386/clone.S:130
0xb7df869e
      Thread [1] 2900 (Suspended : Signal : SIGINT:Interrupt)
            __kernel_vsyscall() at 0xb7fe1424
            __wrap_pthread_cond_wait() at 0xb7fc4815
            __wrap_pthread_cond_wait() at 0xb7fc479e
            main() at /home/generation/Projets/PosixTest/src/Main.cpp:131
0x8048f42


I don't know if this is the same problem but when I launch the real
application, I have some other troubles link with the debug mode.
I investigate about that and I'll inform you later.

Thank you very much.

>
>Also note that I did not replied to you personally, only to the list,
>because otherwise I receive spam from you.
>

I'm sorry about this.

>--
>                                                                Gilles.

[-- Attachment #2: Type: text/html, Size: 8156 bytes --]