[Xenomai-help] Segmentation fault

[Xenomai-help] Segmentation fault

[Oliver Clugnet]

Hello,

I am trying to get the xenomai user-space programs to work on an x86 
embedded system with a uClibc Buildroot root filesystem.
I have patched a kernel, activated the Xenomai sub-system, and 
cross-compiled it with the Buildroot uClibc toolchain as well as the 
userspace programs. The system boots alright with the Xenomai nucleus 
and everything ("dmesg | grep Xenomai" shows that Xenomai is initialised).
But everytime I try to launch a program (cyclictest, clocktest, ...), I 
get a segmentation fault with a kernel error message such as: 
"clocktest[149] general protection ip:804cc22 sp:bfa29594 error:0 in 
clocktest[8048000+7000]".
A possibility I've been looking at is that maybe the programs try to 
access the High Memory, even though /proc/meminfo shows that there is 
none on this system ("HighTotal 0k"), thus the segmentation fault. I 
might add that the system has a 500Mb memory.
Could the High Memory be the problem? Is there a way of getting around it?
Or could the problem be elsewhere?

Regards,

Oliver Clugnet

Re: [Xenomai-help] Segmentation fault

[Gilles Chanteperdrix]

Oliver Clugnet wrote:
> Hello,
> 
> I am trying to get the xenomai user-space programs to work on an x86 
> embedded system with a uClibc Buildroot root filesystem.
> I have patched a kernel, activated the Xenomai sub-system, and 
> cross-compiled it with the Buildroot uClibc toolchain as well as the 
> userspace programs. The system boots alright with the Xenomai nucleus 
> and everything ("dmesg | grep Xenomai" shows that Xenomai is initialised).
> But everytime I try to launch a program (cyclictest, clocktest, ...), I 
> get a segmentation fault with a kernel error message such as: 
> "clocktest[149] general protection ip:804cc22 sp:bfa29594 error:0 in 
> clocktest[8048000+7000]".
> A possibility I've been looking at is that maybe the programs try to 
> access the High Memory, even though /proc/meminfo shows that there is 
> none on this system ("HighTotal 0k"), thus the segmentation fault. I 
> might add that the system has a 500Mb memory.
> Could the High Memory be the problem? Is there a way of getting around it?
> Or could the problem be elsewhere?

No. There is little chance. Chances are higher that the problem comes in
fact from uclibc (on x86, few people use uclibc). Could you try a glibc
rootfs to confirm this hypothesis?

-- 
					    Gilles.

Re: [Xenomai-help] Segmentation fault

[Gilles Chanteperdrix]

Oliver Clugnet wrote:
> On 07/12/2010 11:31 AM, Gilles Chanteperdrix wrote:
>> Oliver Clugnet wrote:
>>    
>>> Hello,
>>>
>>> I am trying to get the xenomai user-space programs to work on an x86
>>> embedded system with a uClibc Buildroot root filesystem.
>>> I have patched a kernel, activated the Xenomai sub-system, and
>>> cross-compiled it with the Buildroot uClibc toolchain as well as the
>>> userspace programs. The system boots alright with the Xenomai nucleus
>>> and everything ("dmesg | grep Xenomai" shows that Xenomai is initialised).
>>> But everytime I try to launch a program (cyclictest, clocktest, ...), I
>>> get a segmentation fault with a kernel error message such as:
>>> "clocktest[149] general protection ip:804cc22 sp:bfa29594 error:0 in
>>> clocktest[8048000+7000]".
>>> A possibility I've been looking at is that maybe the programs try to
>>> access the High Memory, even though /proc/meminfo shows that there is
>>> none on this system ("HighTotal 0k"), thus the segmentation fault. I
>>> might add that the system has a 500Mb memory.
>>> Could the High Memory be the problem? Is there a way of getting around it?
>>> Or could the problem be elsewhere?
>>>      
>> No. There is little chance. Chances are higher that the problem comes in
>> fact from uclibc (on x86, few people use uclibc). Could you try a glibc
>> rootfs to confirm this hypothesis?
>>
>>    
> Hello,
> 
> Thank you for answering so quickly. I am actually in the process of 
> building a glibc root filesystem with Buildroot and a glibc toolchain 
> generated with crosstool-ng, so I will see soon enough if the problem 
> comes form the lib version.
> What I don't understand though, is why the uclibc-x86 combination solely 
> would induce such an error as this one. Does it have something to do 
> with the xenomai compatibility in such a case?

x86 usually have lots of RAM and storage, so people probably never used
uclibc on x86 before you. So, my guess is that it was never tested, and
as such it does not work. By experience, we know that compatibility with
uclibc does not come automatically.

Please do not forget to CC the mailing list.

-- 
					    Gilles.

[Xenomai-help] Segmentation Fault

[Wayne Call]

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

Hi,

When the Xenomai is built, there is a segmentation fault.  What are the
possible scenarios that would cause this error?  There is an "ld terminated
with signal 11" error associated with this fault. 

 

Making all in cyclic

make[3]: Entering directory
`/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/src/
testsuite/cyclic'

/bin/sh ../../../libtool --tag=CC --mode=link bfin-linux-uclibc-gcc     -o
cyclictest
-Wl,@/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/
src/skins/posix/posix.wrappers -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-mfdpic -mfdpic cyclictest-cyclictest.o ../../skins/posix/libpthread_rt.la
-lpthread -lrt

bfin-linux-uclibc-gcc -o .libs/cyclictest
-Wl,@/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/
src/skins/posix/posix.wrappers -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-mfdpic -mfdpic cyclictest-cyclictest.o
../../skins/posix/.libs/libpthread_rt.so -lpthread -lrt -Wl,--rpath
-Wl,/usr/xenomai/lib

collect2: ld terminated with signal 11 [Segmentation fault]

/opt/uClinux/bfin-linux-uclibc/lib/gcc/bfin-linux-uclibc/4.1.1/../../../../b
fin-linux-uclibc/bin/ld: make[3]: *** [cyclictest] Error 1

make[3]: Leaving directory
`/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/src/
testsuite/cyclic'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory
`/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/src/
testsuite'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory
`/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/src'

make: *** [all-recursive] Error 1

 

Wayne

 


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

Re: [Xenomai-help] Segmentation Fault

[Gilles Chanteperdrix]

Wayne Call wrote:
> Hi,
> 
> When the Xenomai is built, there is a segmentation fault.  What are the
> possible scenarios that would cause this error?  There is an "ld terminated
> with signal 11" error associated with this fault. 
> 
>  
> 
> Making all in cyclic
> 
> make[3]: Entering directory
> `/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/src/
> testsuite/cyclic'
> 
> /bin/sh ../../../libtool --tag=CC --mode=link bfin-linux-uclibc-gcc     -o
> cyclictest
> -Wl,@/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/
> src/skins/posix/posix.wrappers -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
> -mfdpic -mfdpic cyclictest-cyclictest.o ../../skins/posix/libpthread_rt.la
> -lpthread -lrt
> 
> bfin-linux-uclibc-gcc -o .libs/cyclictest
> -Wl,@/home/jordanelle/3Star/potomac/Software/magnolia/Kryptic/xenomai-2.3.1/
> src/skins/posix/posix.wrappers -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
> -mfdpic -mfdpic cyclictest-cyclictest.o
> ../../skins/posix/.libs/libpthread_rt.so -lpthread -lrt -Wl,--rpath
> -Wl,/usr/xenomai/lib
> 
> collect2: ld terminated with signal 11 [Segmentation fault]

The most frequent cause of gcc segmentation faults are faulty processors
 (due to over-heating for instance) or RAM. You can run memtest to check
your RAM, or use lm-sensors to check your CPU temperature.

If the error always happens when compiling the same program, then there
may be a bug in your toolchain.

-- 
					    Gilles.

[Xenomai-help] Segmentation Fault

[Dehann Fourie]

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

Hi,

I'm having trouble with a segmentation fault in my real-time application.
The problem seems to occur when I use large amounts of memory. The
application works fine when I don't try to populate the large arrays.

I have tried changing parameters in the real time create call, but this
didn't work. The error message is:

Xenomai: Switching nav to secondary mode after exception #14 from user-space
at 0x804ad13 (pid 1938)
nav [1938]; segfault at 26756e50 eip 0804ad13 esp b762ac28 error 6
Segmentation fault

This is from text mode.

Thanks in advance
Dehann

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

Re: [Xenomai-help] Segmentation Fault

[Gilles Chanteperdrix]

Dehann Fourie wrote:
> Hi,
> 
> I'm having trouble with a segmentation fault in my real-time application.
> The problem seems to occur when I use large amounts of memory. The
> application works fine when I don't try to populate the large arrays.
> 
> I have tried changing parameters in the real time create call, but this
> didn't work. The error message is:
> 
> Xenomai: Switching nav to secondary mode after exception #14 from user-space
> at 0x804ad13 (pid 1938)
> nav [1938]; segfault at 26756e50 eip 0804ad13 esp b762ac28 error 6
> Segmentation fault
> 
> This is from text mode.

You do not give us much information about your configuration. However,
have you tried gdb ? In case of segmentation faults, it should stop you
right at the point where the segmentation occurs.

-- 
					    Gilles.

Re: [Xenomai-help] Segmentation Fault

[Dehann Fourie]

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

Hi,

Sorry for the lack of information, I'm still bit of a new guy. I have found
the following (I do use a mlockall(current | future)):

When i declare larger arrays in the real-time task I get the segmentation
fault. This is when I declare as follows
double arr[10000]; //some KB sized value

When I use malloc I don't get the problem. My question now is where does the
first one declare the memory. I am assuming that the malloc declares strait
into the RAM, becuase there I am safe to declare a couple of MB?

Thanks
Dehann

On Fri, Sep 26, 2008 at 5:55 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Dehann Fourie wrote:
> > Hi,
> >
> > I'm having trouble with a segmentation fault in my real-time application.
> > The problem seems to occur when I use large amounts of memory. The
> > application works fine when I don't try to populate the large arrays.
> >
> > I have tried changing parameters in the real time create call, but this
> > didn't work. The error message is:
> >
> > Xenomai: Switching nav to secondary mode after exception #14 from
> user-space
> > at 0x804ad13 (pid 1938)
> > nav [1938]; segfault at 26756e50 eip 0804ad13 esp b762ac28 error 6
> > Segmentation fault
> >
> > This is from text mode.
>
> You do not give us much information about your configuration. However,
> have you tried gdb ? In case of segmentation faults, it should stop you
> right at the point where the segmentation occurs.
>
> --
>                                             Gilles.
>

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

Re: [Xenomai-help] Segmentation Fault

[Gilles Chanteperdrix]

Dehann Fourie wrote:
> Hi,
> 
> Sorry for the lack of information, I'm still bit of a new guy. I have found
> the following (I do use a mlockall(current | future)):
> 
> When i declare larger arrays in the real-time task I get the segmentation
> fault. This is when I declare as follows
> double arr[10000]; //some KB sized value
> 
> When I use malloc I don't get the problem. My question now is where does the
> first one declare the memory. I am assuming that the malloc declares strait
> into the RAM, becuase there I am safe to declare a couple of MB?

It depends on where you declare double arr[10000]. If this is outside of
any scope, then it ends up in an anonmous map. If this is declared in a
function, then it ends up on the current thread stack, so, in this case
the current thread stack has to be large enough to allow such an
allocation (in your case, sizeof(arr) == 80000, that is around 80Kbytes).

-- 
					    Gilles.