All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Issues with Xenomai 3.0.5...
@ 2017-06-04 16:34 Jim Langston
  2017-06-04 16:43 ` Philippe Gerum
  0 siblings, 1 reply; 8+ messages in thread
From: Jim Langston @ 2017-06-04 16:34 UTC (permalink / raw)
  To: xenomai

Hello,

I am attempting to run Xenomai 3.0.5 on an embedded system.

It is being built using Buildroot 2017.02.2, Xenomai 3.0.5, Kernel 4.1.18,
Adeos patch 4.1.18 #9.

The resultant image boots, and I can see that Xenomai is running:


*dmesg | grep -i xeno*
[    1.233003] [Xenomai] scheduling class idle registered.
[    1.233098] [Xenomai] scheduling class rt registered.
[    1.233373] I-pipe: head domain Xenomai registered.
[    1.236591] [Xenomai] Cobalt v3.0.5 (Sisyphus's Boulder)
[    2.208662] udevd[664]: specified group 'xenomai' unknown

But attempting to run ANY of the test apps for Xenomai segfaults:


*strace latency*
execve("/usr/bin/latency", ["latency"], [/* 11 vars */]) = 0
readlinkat(AT_FDCWD, "/proc/self/exe", "/usr/bin/latency", 4096) = 16
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb7768000
open("/lib/libcobalt.so.2", O_RDONLY)   = -1 ENOENT (No such file or
directory)
open("/lib/libcobalt.so.2", O_RDONLY)   = -1 ENOENT (No such file or
directory)
open("/usr/lib/libcobalt.so.2", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=143764, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb7767000
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\211\0\0004\0\0\0"...,
4096) = 4096
mmap2(NULL, 114688, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb774b000
mmap2(0xb774b000, 104088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xb774b000
mmap2(0xb7765000, 4584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x19000) = 0xb7765000
close(3)                                = 0
munmap(0xb7767000, 4096)                = 0
open("/lib/libmodechk.so.0", O_RDONLY)  = -1 ENOENT (No such file or
directory)
open("/lib/libmodechk.so.0", O_RDONLY)  = -1 ENOENT (No such file or
directory)
open("/usr/lib/libmodechk.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=5476, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb7767000
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\370\4\0\0004\0\0\0"...,
4096) = 4096
mmap2(NULL, 8192, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7749000
mmap2(0xb7749000, 2120, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0xb7749000
mmap2(0xb774a000, 2376, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xb774a000
close(3)                                = 0
munmap(0xb7767000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=644488, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb7767000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
\343\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 610304, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb76b4000
mmap2(0xb76b4000, 507852, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xb76b4000
mmap2(0xb7731000, 4846, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x7c000) = 0xb7731000
mmap2(0xb7733000, 88360, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7733000
close(3)                                = 0
munmap(0xb7767000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=644488, ...}) = 0
close(3)                                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=644488, ...}) = 0
close(3)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=28764, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb7767000
set_thread_area({entry_number:-1, base_addr:0xb77676a0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0 (entry_number:6)
mprotect(0xb7731000, 4096, PROT_READ)   = 0
mprotect(0xb7772000, 4096, PROT_READ)   = 0
set_tid_address(0xb7767708)             = 774
set_robust_list(0xb776770c, 12)         = 0
rt_sigaction(SIGRTMIN, {sa_handler=0xb770517c, sa_mask=[],
sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0xb76c3cb7}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0xb77050b7, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0xb76c3cb7}, NULL,
8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sysname="Linux", nodename="buildroot", ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
open("/proc/self/cmdline", O_RDONLY)    = 3
brk(NULL)                               = 0x956b000
brk(0x956c000)                          = 0x956c000
read(3, "latency\0", 1024)              = 8
close(3)                                = 0
gettid()                                = 774
rt_sigaction(SIGILL, {sa_handler=0xb7754c64, sa_mask=[ILL],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0xb76c3cbe},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGILL, {sa_handler=SIG_DFL, sa_mask=[ILL],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0xb76c3cbe},
{sa_handler=0xb7754c64, sa_mask=[ILL], sa_flags=SA_RESTORER|SA_RESTART,
sa_restorer=0xb76c3cbe}, 8) = 0
mlockall(MCL_CURRENT|MCL_FUTURE)        = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++
Segmentation fault

(Sorry about the length)

Any ideas on where i could start looking about?  I don't see any causality
here...

Thanks,
Jim

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-04 16:34 [Xenomai] Issues with Xenomai 3.0.5 Jim Langston
@ 2017-06-04 16:43 ` Philippe Gerum
  2017-06-04 16:54   ` Jim Langston
  2017-06-04 18:02   ` Jim Langston
  0 siblings, 2 replies; 8+ messages in thread
From: Philippe Gerum @ 2017-06-04 16:43 UTC (permalink / raw)
  To: jlangston, xenomai

On 06/04/2017 06:34 PM, Jim Langston wrote:
> Hello,
> 
> I am attempting to run Xenomai 3.0.5 on an embedded system.
> 
> It is being built using Buildroot 2017.02.2, Xenomai 3.0.5, Kernel 4.1.18,
> Adeos patch 4.1.18 #9.

I cannot infere the CPU architecture from this information.

> The resultant image boots, and I can see that Xenomai is running:
> 

[snip]

> > Any ideas on where i could start looking about?  I don't see any causality
> here...
> 

Could you run the latency utility over gdb and get a stack backtrace
when it breaks?

For the backtrace to be meaningful, you will need to pass
--enable-debug=symbols to the configure script for building Xenomai's
user-space libs and programs.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-04 16:43 ` Philippe Gerum
@ 2017-06-04 16:54   ` Jim Langston
  2017-06-04 18:02   ` Jim Langston
  1 sibling, 0 replies; 8+ messages in thread
From: Jim Langston @ 2017-06-04 16:54 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: xenomai

Thank you for taking time to respond to me!

The CPU is an old Geode LX processor:

*uname -a *

Linux buildroot 4.1.18 #2 SMP Sun Jun 4 10:23:36 EDT 2017 i586 GNU/Linux

I'll have a go at getting a GDB backtrace and post back.

Again, thanks!

Jim

On Sun, Jun 4, 2017 at 12:43 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 06/04/2017 06:34 PM, Jim Langston wrote:
> > Hello,
> >
> > I am attempting to run Xenomai 3.0.5 on an embedded system.
> >
> > It is being built using Buildroot 2017.02.2, Xenomai 3.0.5, Kernel
> 4.1.18,
> > Adeos patch 4.1.18 #9.
>
> I cannot infere the CPU architecture from this information.
>
> > The resultant image boots, and I can see that Xenomai is running:
> >
>
> [snip]
>
> > > Any ideas on where i could start looking about?  I don't see any
> causality
> > here...
> >
>
> Could you run the latency utility over gdb and get a stack backtrace
> when it breaks?
>
> For the backtrace to be meaningful, you will need to pass
> --enable-debug=symbols to the configure script for building Xenomai's
> user-space libs and programs.
>
> --
> Philippe.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-04 16:43 ` Philippe Gerum
  2017-06-04 16:54   ` Jim Langston
@ 2017-06-04 18:02   ` Jim Langston
  2017-06-05  8:24     ` Philippe Gerum
  1 sibling, 1 reply; 8+ messages in thread
From: Jim Langston @ 2017-06-04 18:02 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: xenomai

Philippe,

The backtrace I get when I run gdb on the target is:

#0  0x00000000 in ?? ()
#1  0xb77b617c in do_open (
    path=path@entry=0xb77bd31d "/dev/rtdm/memdev-private",
    oflag=oflag@entry=2, mode=0) at rtdm.c:51
#2  0xb77b61dc in __cobalt_open (path=0xb77bd31d
"/dev/rtdm/memdev-private",
    oflag=2) at rtdm.c:74
#3  0xb77b844d in __map_umm (
    name=name@entry=0xb77bd31d "/dev/rtdm/memdev-private",
    size_r=size_r@entry=0xb77c53b0 <private_size>) at umm.c:53
#4  0xb77b8506 in init_bind () at umm.c:110
#5  0xb7722aa5 in pthread_once () from /lib/libc.so.0
#6  0xb77b85cd in cobalt_init_umm (vdso_offset=0) at umm.c:133
#7  0xb77b3acf in low_init () at init.c:128
#8  0xb77b3b3c in __cobalt_init () at init.c:147
#9  cobalt_init () at init.c:198
#10 0xb77ba7b3 in __xenomai_init (argcp=argcp@entry=0xbfc9f0c0,
    argvp=argvp@entry=0xbfc9f0bc, me=me@entry=0xb77bdf56 "program")
    at setup.c:574
#11 0xb77ba8d1 in xenomai_init (argcp=0xbfc9f0c0, argvp=0xbfc9f0bc)
    at setup.c:629
#12 0x08049565 in call_init (argvp=0xbfc9f0bc, argcp=0xbfc9f0c0)
    at bootstrap.c:76
#13 xenomai_bootstrap () at bootstrap.c:140
#14 0x0804b180 in __do_global_ctors_aux ()
#15 0x08049011 in _init ()
#16 0xb77554a3 in __uClibc_main () from /lib/libc.so.0
#17 0x08049b05 in _start ()

'/dev/rtdm/memdev-private' does exist in the filesystem, and has the
following settings:

crw-rw----    1    root    root    252

I hope this helps.  Thanks again for responding.

Jim


On Sun, Jun 4, 2017 at 12:43 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 06/04/2017 06:34 PM, Jim Langston wrote:
> > Hello,
> >
> > I am attempting to run Xenomai 3.0.5 on an embedded system.
> >
> > It is being built using Buildroot 2017.02.2, Xenomai 3.0.5, Kernel
> 4.1.18,
> > Adeos patch 4.1.18 #9.
>
> I cannot infere the CPU architecture from this information.
>
> > The resultant image boots, and I can see that Xenomai is running:
> >
>
> [snip]
>
> > > Any ideas on where i could start looking about?  I don't see any
> causality
> > here...
> >
>
> Could you run the latency utility over gdb and get a stack backtrace
> when it breaks?
>
> For the backtrace to be meaningful, you will need to pass
> --enable-debug=symbols to the configure script for building Xenomai's
> user-space libs and programs.
>
> --
> Philippe.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-04 18:02   ` Jim Langston
@ 2017-06-05  8:24     ` Philippe Gerum
  2017-06-06  2:12       ` Jim Langston
  0 siblings, 1 reply; 8+ messages in thread
From: Philippe Gerum @ 2017-06-05  8:24 UTC (permalink / raw)
  To: jlangston; +Cc: xenomai

On 06/04/2017 08:02 PM, Jim Langston wrote:
> Philippe,
> 
> The backtrace I get when I run gdb on the target is:
> 
> #0  0x00000000 in ?? ()
> #1  0xb77b617c in do_open (
>     path=path@entry=0xb77bd31d "/dev/rtdm/memdev-private",
>     oflag=oflag@entry=2, mode=0) at rtdm.c:51

It looks like the *libc you are using does not enable the
sysenter/sysexit kernel call convention for x86, you may want to pass
--disable-x86-vsyscall to the configure script, then rebuild from scratch.

Also, I would recommend to pass --disable-smp in the same move, since
Xenomai enables SMP support by default for the x86 architecture, and
although this would still work with a UP kernel (the opposite would
not), there is no point on the Geode.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-05  8:24     ` Philippe Gerum
@ 2017-06-06  2:12       ` Jim Langston
  2017-06-06  7:41         ` Philippe Gerum
  0 siblings, 1 reply; 8+ messages in thread
From: Jim Langston @ 2017-06-06  2:12 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: xenomai

Philippe,

That worked well, thank you!

Now that my test applications are running, I wanted to be sure that
everything was kosher.  If I run 'latency' or 'switchtest' and press CTRL+C
to stop them, I get a seg fault.  Otherwise they seem to run normally,
basically the same as my old 2.X Xenomai systems.

*gdb latency*

Thread 4 "sampling-1035" received signal SIGXCPU, CPU time limit exceeded.

#0  0xb770c25d in __cobalt_read (fd=3, buf=0xb74373a8, nbyte=8) at
rtdm.c:180
#1  0x08049e60 in latency (cookie=0x0) at latency.c:165
#2  0xb770d760 in cobalt_thread_trampoline (p=0xbfff47bc) at thread.c:166
#3  0xb76bc5bc in start_thread () from /lib/libc.so.0
#4  0xb7678ded in clone () from /lib/libc.so.0


*gdb switchtest*
Thread 18 "rtuo_ufps-20" received signal SIG32, Real-time event 32.

#0  0xb7729f42 in do_ioctl (fd=fd@entry=3, request=request@entry=2148009525,

    arg=arg@entry=0xb718d358) at rtdm.c:132
#1  0xb772a204 in __cobalt_ioctl (fd=3, request=2148009525) at rtdm.c:167
#2  0x0804b1a5 in rtuo (cookie=0x97bec30) at switchtest.c:654
#3  0xb772b760 in cobalt_thread_trampoline (p=0xbfb88afc) at thread.c:166
#4  0xb76da5bc in start_thread () from /lib/libc.so.0
#5  0xb7696ded in clone () from /lib/libc.so.0

Is this normal, or do I need to do some more digging through my build
environment?

Thanks,
Jim

On Mon, Jun 5, 2017 at 4:24 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 06/04/2017 08:02 PM, Jim Langston wrote:
> > Philippe,
> >
> > The backtrace I get when I run gdb on the target is:
> >
> > #0  0x00000000 in ?? ()
> > #1  0xb77b617c in do_open (
> >     path=path@entry=0xb77bd31d "/dev/rtdm/memdev-private",
> >     oflag=oflag@entry=2, mode=0) at rtdm.c:51
>
> It looks like the *libc you are using does not enable the
> sysenter/sysexit kernel call convention for x86, you may want to pass
> --disable-x86-vsyscall to the configure script, then rebuild from scratch.
>
> Also, I would recommend to pass --disable-smp in the same move, since
> Xenomai enables SMP support by default for the x86 architecture, and
> although this would still work with a UP kernel (the opposite would
> not), there is no point on the Geode.
>
> --
> Philippe.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-06  2:12       ` Jim Langston
@ 2017-06-06  7:41         ` Philippe Gerum
  2017-06-07  5:29           ` Philippe Gerum
  0 siblings, 1 reply; 8+ messages in thread
From: Philippe Gerum @ 2017-06-06  7:41 UTC (permalink / raw)
  To: jlangston; +Cc: xenomai

On 06/06/2017 04:12 AM, Jim Langston wrote:
> Philippe,
> 
> That worked well, thank you!
> 
> Now that my test applications are running, I wanted to be sure that
> everything was kosher.  If I run 'latency' or 'switchtest' and press
> CTRL+C to stop them, I get a seg fault.

Receiving SIGSEGV/SIGBUS/SIGILL is 100% abnormal. Can you send the stack
backtrace of such fault over gdb?

  Otherwise they seem to run
> normally, basically the same as my old 2.X Xenomai systems.
> 
> *gdb latency*
> 
> Thread 4 "sampling-1035" received signal SIGXCPU, CPU time limit exceeded.

This is a watchdog trigger (CONFIG_XENO_OPT_WATCHDOG) after 4s spent
running purely real-time stuff without leaving any cycles to the regular
kernel, which denotes a problem. On x86, the default real-time sampling
period for latency testing is 100 us, which may be a bit too fast for a
Geode LX. You may want to try latency -p 200 or higher.

Also, you should make sure to turn off any time consuming debug option
in kernel space, e.g. DEBUG_VM, DEBUG_LIST, XENO_OPT_DEBUG_LOCKING,
IPIPE_TRACE etc.

For actual latency testing, disabling debug in the user-space support
(--disable-debug) is better too, since this option has some overhead,
except --enable-debug=symbols, which only adds -g to the compilation
flags but keeps the optimizer enabled (-O2).

> 
> #0  0xb770c25d in __cobalt_read (fd=3, buf=0xb74373a8, nbyte=8) at
> rtdm.c:180
> #1  0x08049e60 in latency (cookie=0x0) at latency.c:165
> #2  0xb770d760 in cobalt_thread_trampoline (p=0xbfff47bc) at thread.c:166
> #3  0xb76bc5bc in start_thread () from /lib/libc.so.0
> #4  0xb7678ded in clone () from /lib/libc.so.0*
> 
> *
> *gdb switchtest
> *
> Thread 18 "rtuo_ufps-20" received signal SIG32, Real-time event 32.
> 
> #0  0xb7729f42 in do_ioctl (fd=fd@entry=3,
> request=request@entry=2148009525,
>     arg=arg@entry=0xb718d358) at rtdm.c:132
> #1  0xb772a204 in __cobalt_ioctl (fd=3, request=2148009525) at rtdm.c:167
> #2  0x0804b1a5 in rtuo (cookie=0x97bec30) at switchtest.c:654
> #3  0xb772b760 in cobalt_thread_trampoline (p=0xbfb88afc) at thread.c:166
> #4  0xb76da5bc in start_thread () from /lib/libc.so.0
> #5  0xb7696ded in clone () from /lib/libc.so.0*
> 
> *
> Is this normal, or do I need to do some more digging through my build
> environment?
> 

I can make sense of a Cobalt-based application receiving SIGXCPU and
SIGWINCH from the real-time core for internal purposes, but I don't have
any explanation for SIGRTMIN at the moment.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Xenomai] Issues with Xenomai 3.0.5...
  2017-06-06  7:41         ` Philippe Gerum
@ 2017-06-07  5:29           ` Philippe Gerum
  0 siblings, 0 replies; 8+ messages in thread
From: Philippe Gerum @ 2017-06-07  5:29 UTC (permalink / raw)
  To: jlangston; +Cc: xenomai

On 06/06/2017 09:41 AM, Philippe Gerum wrote:
> On 06/06/2017 04:12 AM, Jim Langston wrote:
>> Philippe,
>>
>> That worked well, thank you!
>>
>> Now that my test applications are running, I wanted to be sure that
>> everything was kosher.  If I run 'latency' or 'switchtest' and press
>> CTRL+C to stop them, I get a seg fault.
> 
> Receiving SIGSEGV/SIGBUS/SIGILL is 100% abnormal. Can you send the stack
> backtrace of such fault over gdb?
> 
>   Otherwise they seem to run
>> normally, basically the same as my old 2.X Xenomai systems.
>>
>> *gdb latency*
>>
>> Thread 4 "sampling-1035" received signal SIGXCPU, CPU time limit exceeded.
> 
> This is a watchdog trigger (CONFIG_XENO_OPT_WATCHDOG) after 4s spent
> running purely real-time stuff without leaving any cycles to the regular
> kernel, which denotes a problem. On x86, the default real-time sampling
> period for latency testing is 100 us, which may be a bit too fast for a
> Geode LX. You may want to try latency -p 200 or higher.
> 
> Also, you should make sure to turn off any time consuming debug option
> in kernel space, e.g. DEBUG_VM, DEBUG_LIST, XENO_OPT_DEBUG_LOCKING,
> IPIPE_TRACE etc.
> 
> For actual latency testing, disabling debug in the user-space support
> (--disable-debug) is better too, since this option has some overhead,
> except --enable-debug=symbols, which only adds -g to the compilation
> flags but keeps the optimizer enabled (-O2).
> 
>>
>> #0  0xb770c25d in __cobalt_read (fd=3, buf=0xb74373a8, nbyte=8) at
>> rtdm.c:180
>> #1  0x08049e60 in latency (cookie=0x0) at latency.c:165
>> #2  0xb770d760 in cobalt_thread_trampoline (p=0xbfff47bc) at thread.c:166
>> #3  0xb76bc5bc in start_thread () from /lib/libc.so.0
>> #4  0xb7678ded in clone () from /lib/libc.so.0*
>>
>> *
>> *gdb switchtest
>> *
>> Thread 18 "rtuo_ufps-20" received signal SIG32, Real-time event 32.
>>
>> #0  0xb7729f42 in do_ioctl (fd=fd@entry=3,
>> request=request@entry=2148009525,
>>     arg=arg@entry=0xb718d358) at rtdm.c:132
>> #1  0xb772a204 in __cobalt_ioctl (fd=3, request=2148009525) at rtdm.c:167
>> #2  0x0804b1a5 in rtuo (cookie=0x97bec30) at switchtest.c:654
>> #3  0xb772b760 in cobalt_thread_trampoline (p=0xbfb88afc) at thread.c:166
>> #4  0xb76da5bc in start_thread () from /lib/libc.so.0
>> #5  0xb7696ded in clone () from /lib/libc.so.0*
>>
>> *
>> Is this normal, or do I need to do some more digging through my build
>> environment?
>>
> 
> I can make sense of a Cobalt-based application receiving SIGXCPU and
> SIGWINCH from the real-time core for internal purposes, but I don't have
> any explanation for SIGRTMIN at the moment.
> 

SIGRTMIN is used by the NPTL library internally for implementing
pthread_cancel(), gdb notices this signal received by the debuggee.
The backtrace above does not reflect a segfault, this is only a report
about receiving SIGRTMIN.

Passing "handle 32 pass noprint nostop" to gdb prior to running the app
would disable such reporting, and would not prompt the user for acting
upon it either.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-06-07  5:29 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-04 16:34 [Xenomai] Issues with Xenomai 3.0.5 Jim Langston
2017-06-04 16:43 ` Philippe Gerum
2017-06-04 16:54   ` Jim Langston
2017-06-04 18:02   ` Jim Langston
2017-06-05  8:24     ` Philippe Gerum
2017-06-06  2:12       ` Jim Langston
2017-06-06  7:41         ` Philippe Gerum
2017-06-07  5:29           ` Philippe Gerum

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.