From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2b490f270809301326jd381307md432bd4cdfe36d3b@domain.hid> Date: Tue, 30 Sep 2008 22:26:40 +0200 From: "Dehann Fourie" In-Reply-To: <48DD05F2.4040203@domain.hid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68034_4668195.1222806400198" References: <2b490f270809260610w4573446x507ef059d4b3ca0b@domain.hid> <48DD05F2.4040203@domain.hid> Subject: Re: [Xenomai-help] Segmentation Fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org ------=_Part_68034_4668195.1222806400198 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. > ------=_Part_68034_4668195.1222806400198 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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.

------=_Part_68034_4668195.1222806400198-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2b490f270809260610w4573446x507ef059d4b3ca0b@domain.hid> Date: Fri, 26 Sep 2008 15:10:35 +0200 From: "Dehann Fourie" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16343_18422410.1222434635287" Subject: [Xenomai-help] Segmentation Fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org ------=_Part_16343_18422410.1222434635287 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ------=_Part_16343_18422410.1222434635287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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
------=_Part_16343_18422410.1222434635287-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48DD05F2.4040203@domain.hid> Date: Fri, 26 Sep 2008 17:55:30 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <2b490f270809260610w4573446x507ef059d4b3ca0b@domain.hid> In-Reply-To: <2b490f270809260610w4573446x507ef059d4b3ca0b@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Segmentation Fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dehann Fourie Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48E7CDA7.1010102@domain.hid> Date: Sat, 04 Oct 2008 22:10:15 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <2b490f270809260610w4573446x507ef059d4b3ca0b@domain.hid> <48DD05F2.4040203@domain.hid> <2b490f270809301326jd381307md432bd4cdfe36d3b@domain.hid> In-Reply-To: <2b490f270809301326jd381307md432bd4cdfe36d3b@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Segmentation Fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dehann Fourie Cc: Xenomai help 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wayne Call" Date: Tue, 3 Mar 2009 11:55:46 -0700 Message-ID: <000001c99c31$aa5d46a0$ff17d3e0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C99BF6.FDFE6EA0" Content-Language: en-us Subject: [Xenomai-help] Segmentation Fault Reply-To: wcall@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "'Xenomai-help@domain.hid'" This is a multipart message in MIME format. ------=_NextPart_000_0001_01C99BF6.FDFE6EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0001_01C99BF6.FDFE6EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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/s= rc/testsuite/cyclic'

/bin/sh ../../../libtool --tag=3DCC --mode=3Dlink = 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-uclib= c/4.1.1/../../../../bfin-linux-uclibc/bin/ld: make[3]: *** [cyclictest] Error 1

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

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

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

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

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

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

 

Wayne

 

------=_NextPart_000_0001_01C99BF6.FDFE6EA0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49AD800B.4040201@domain.hid> Date: Tue, 03 Mar 2009 20:07:55 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <000001c99c31$aa5d46a0$ff17d3e0$@com> In-Reply-To: <000001c99c31$aa5d46a0$ff17d3e0$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Segmentation Fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: wcall@domain.hid Cc: "'Xenomai-help@domain.hid'" 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C3ADF54.1080507@domain.hid> Date: Mon, 12 Jul 2010 11:24:36 +0200 From: Oliver Clugnet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Xenomai-help] Segmentation fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C3AE0F2.3070908@domain.hid> Date: Mon, 12 Jul 2010 11:31:30 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4C3ADF54.1080507@domain.hid> In-Reply-To: <4C3ADF54.1080507@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Segmentation fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Oliver Clugnet Cc: xenomai@xenomai.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C3AE459.5080108@domain.hid> Date: Mon, 12 Jul 2010 11:46:01 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4C3ADF54.1080507@domain.hid> <4C3AE0F2.3070908@domain.hid> <4C3AE2EE.9050701@domain.hid> In-Reply-To: <4C3AE2EE.9050701@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Segmentation fault List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Oliver Clugnet Cc: Xenomai help 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.