>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.