* [Xenomai] Mixing Posix RT APIs and vxWorks APIs
@ 2016-04-04 13:42 Alex Plits
2016-04-05 7:02 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-04-04 13:42 UTC (permalink / raw)
To: xenomai
Hi,
We are currently porting some of our vxWorks xenomai (copperplate) APIs we use in our application to
Posix (cobalt I guess). We have started with the VxWorks "tasks" but it seems that we're getting strange behavior on
The remaining VxWorks APIs when used from the POSIX generated tasks (threads is the right word in posix) e.g. MsqQRecv function gets segfault but when it is used From a VxWorks generated task it works fine.
I understand from the comments in code it should work but I was wondering if there are known issues.
We are using currently xenomai 3 rc-6 (I saw there were fixes in xenomai 3.0.2).
Thanks in advance,
Alex Plits.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-04 13:42 [Xenomai] Mixing Posix RT APIs and vxWorks APIs Alex Plits
@ 2016-04-05 7:02 ` Gilles Chanteperdrix
2016-04-07 5:56 ` Alex Plits
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2016-04-05 7:02 UTC (permalink / raw)
To: Alex Plits; +Cc: xenomai
On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> Hi,
>
> We are currently porting some of our vxWorks xenomai (copperplate) APIs we use in our application to
> Posix (cobalt I guess).
Well, if you do not know whether you are using Cobalt or Mercury, we
can not know it for you...
> We have started with the VxWorks "tasks" but it seems that we're getting strange behavior on
> The remaining VxWorks APIs when used from the POSIX generated tasks (threads is the right word in posix) e.g. MsqQRecv function gets segfault but when it is used From a VxWorks generated task it works fine.
> I understand from the comments in code it should work but I was wondering if there are known issues.
>
> We are using currently xenomai 3 rc-6 (I saw there were fixes in xenomai 3.0.2).
Could you send a self-contained, simplest possible test case which
causes the problem for you, that we can test on the latest Xenomai
release to see if the problem has not been already fixed?
Regards.
--
Gilles.
https://click-hack.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-05 7:02 ` Gilles Chanteperdrix
@ 2016-04-07 5:56 ` Alex Plits
2016-04-07 17:56 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-04-07 5:56 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Tuesday, April 05, 2016 10:03 AM
> To: Alex Plits
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> > Hi,
> >
> > We are currently porting some of our vxWorks xenomai (copperplate)
> > APIs we use in our application to Posix (cobalt I guess).
>
> Well, if you do not know whether you are using Cobalt or Mercury, we can
> not know it for you...
[Alex Plits]
Cobalt :)
>
> > We have started with the VxWorks "tasks" but it seems that we're
> > getting strange behavior on The remaining VxWorks APIs when used from
> the POSIX generated tasks (threads is the right word in posix) e.g. MsqQRecv
> function gets segfault but when it is used From a VxWorks generated task it
> works fine.
> > I understand from the comments in code it should work but I was
> wondering if there are known issues.
> >
> > We are using currently xenomai 3 rc-6 (I saw there were fixes in xenomai
> 3.0.2).
>
> Could you send a self-contained, simplest possible test case which causes the
> problem for you, that we can test on the latest Xenomai release to see if the
> problem has not been already fixed?
>
[Alex Plits]
Attached code that is ripped from xenomai examples and initiates 2 threads using posix api then uses VxWorks MsgQ to communicate.
Please advise if this code works as expected - it seems that when we use WAIT_FOREVER flag we have an issue.
Sorry in advance for the #ifdef's and comments in code -
Thanks,
Alex Plits.
> Regards.
>
> --
> Gilles.
> https://click-hack.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: posix_vxworks_test.c
URL: <http://xenomai.org/pipermail/xenomai/attachments/20160407/e52fcb1d/attachment.c>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-07 5:56 ` Alex Plits
@ 2016-04-07 17:56 ` Philippe Gerum
2016-04-25 10:03 ` Alex Plits
0 siblings, 1 reply; 13+ messages in thread
From: Philippe Gerum @ 2016-04-07 17:56 UTC (permalink / raw)
To: Alex Plits, Gilles Chanteperdrix; +Cc: xenomai
On 04/07/2016 07:56 AM, Alex Plits wrote:
>
>
>> -----Original Message-----
>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Sent: Tuesday, April 05, 2016 10:03 AM
>> To: Alex Plits
>> Cc: xenomai@xenomai.org
>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>
>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
>>> Hi,
>>>
>>> We are currently porting some of our vxWorks xenomai (copperplate)
>>> APIs we use in our application to Posix (cobalt I guess).
>>
>> Well, if you do not know whether you are using Cobalt or Mercury, we can
>> not know it for you...
> [Alex Plits]
> Cobalt :)
>>
>>> We have started with the VxWorks "tasks" but it seems that we're
>>> getting strange behavior on The remaining VxWorks APIs when used from
>> the POSIX generated tasks (threads is the right word in posix) e.g. MsqQRecv
>> function gets segfault but when it is used From a VxWorks generated task it
>> works fine.
>>> I understand from the comments in code it should work but I was
>> wondering if there are known issues.
>>>
>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in xenomai
>> 3.0.2).
>>
>> Could you send a self-contained, simplest possible test case which causes the
>> problem for you, that we can test on the latest Xenomai release to see if the
>> problem has not been already fixed?
>>
> [Alex Plits]
> Attached code that is ripped from xenomai examples and initiates 2 threads using posix api then uses VxWorks MsgQ to communicate.
> Please advise if this code works as expected - it seems that when we use WAIT_FOREVER flag we have an issue.
>
> Sorry in advance for the #ifdef's and comments in code -
For the record, 3.0-rc6 won't work properly with --enable-pshared
setups. For sane shared processing involving multiple copperplate-based
APIs (such as VxWorks), you do need 3.0.2.
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-07 17:56 ` Philippe Gerum
@ 2016-04-25 10:03 ` Alex Plits
2016-04-25 10:38 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-04-25 10:03 UTC (permalink / raw)
To: Philippe Gerum, Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Thursday, April 07, 2016 8:56 PM
> To: Alex Plits; Gilles Chanteperdrix
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
> On 04/07/2016 07:56 AM, Alex Plits wrote:
> >
> >
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> >> Sent: Tuesday, April 05, 2016 10:03 AM
> >> To: Alex Plits
> >> Cc: xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>
> >> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> >>> Hi,
> >>>
> >>> We are currently porting some of our vxWorks xenomai (copperplate)
> >>> APIs we use in our application to Posix (cobalt I guess).
> >>
> >> Well, if you do not know whether you are using Cobalt or Mercury, we
> >> can not know it for you...
> > [Alex Plits]
> > Cobalt :)
> >>
> >>> We have started with the VxWorks "tasks" but it seems that we're
> >>> getting strange behavior on The remaining VxWorks APIs when used
> >>> from
> >> the POSIX generated tasks (threads is the right word in posix) e.g.
> >> MsqQRecv function gets segfault but when it is used From a VxWorks
> >> generated task it works fine.
> >>> I understand from the comments in code it should work but I was
> >> wondering if there are known issues.
> >>>
> >>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
> >>> xenomai
> >> 3.0.2).
> >>
> >> Could you send a self-contained, simplest possible test case which
> >> causes the problem for you, that we can test on the latest Xenomai
> >> release to see if the problem has not been already fixed?
> >>
> > [Alex Plits]
> > Attached code that is ripped from xenomai examples and initiates 2
> threads using posix api then uses VxWorks MsgQ to communicate.
> > Please advise if this code works as expected - it seems that when we use
> WAIT_FOREVER flag we have an issue.
> >
> > Sorry in advance for the #ifdef's and comments in code -
>
> For the record, 3.0-rc6 won't work properly with --enable-pshared setups.
> For sane shared processing involving multiple copperplate-based APIs (such
> as VxWorks), you do need 3.0.2.
[Alex Plits]
We have configured --enable-pshared on xenomai 3.0.2 and now compiling empty application (just empty main routine) using non posix skin e.g. vxworks or even alchemy causes the
"Bus error" in runtime(see below). Removing --enable-pshared bootstrap completes successfully.
# ./posixvx --trace=1
-- xenomai_init() running
-- cobalt->init()
-- connected to Cobalt
-- memory locked
-- memory heaps mapped
-- boilerplate->init()
-- copperplate->init()
Bus error
>
> --
> Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-25 10:03 ` Alex Plits
@ 2016-04-25 10:38 ` Philippe Gerum
2016-04-25 10:41 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Philippe Gerum @ 2016-04-25 10:38 UTC (permalink / raw)
To: Alex Plits, Gilles Chanteperdrix; +Cc: xenomai
On 04/25/2016 12:03 PM, Alex Plits wrote:
>
>
>> -----Original Message-----
>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>> Sent: Thursday, April 07, 2016 8:56 PM
>> To: Alex Plits; Gilles Chanteperdrix
>> Cc: xenomai@xenomai.org
>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>
>> On 04/07/2016 07:56 AM, Alex Plits wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>>>> Sent: Tuesday, April 05, 2016 10:03 AM
>>>> To: Alex Plits
>>>> Cc: xenomai@xenomai.org
>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>>>
>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
>>>>> Hi,
>>>>>
>>>>> We are currently porting some of our vxWorks xenomai (copperplate)
>>>>> APIs we use in our application to Posix (cobalt I guess).
>>>>
>>>> Well, if you do not know whether you are using Cobalt or Mercury, we
>>>> can not know it for you...
>>> [Alex Plits]
>>> Cobalt :)
>>>>
>>>>> We have started with the VxWorks "tasks" but it seems that we're
>>>>> getting strange behavior on The remaining VxWorks APIs when used
>>>>> from
>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
>>>> MsqQRecv function gets segfault but when it is used From a VxWorks
>>>> generated task it works fine.
>>>>> I understand from the comments in code it should work but I was
>>>> wondering if there are known issues.
>>>>>
>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
>>>>> xenomai
>>>> 3.0.2).
>>>>
>>>> Could you send a self-contained, simplest possible test case which
>>>> causes the problem for you, that we can test on the latest Xenomai
>>>> release to see if the problem has not been already fixed?
>>>>
>>> [Alex Plits]
>>> Attached code that is ripped from xenomai examples and initiates 2
>> threads using posix api then uses VxWorks MsgQ to communicate.
>>> Please advise if this code works as expected - it seems that when we use
>> WAIT_FOREVER flag we have an issue.
>>>
>>> Sorry in advance for the #ifdef's and comments in code -
>>
>> For the record, 3.0-rc6 won't work properly with --enable-pshared setups.
>> For sane shared processing involving multiple copperplate-based APIs (such
>> as VxWorks), you do need 3.0.2.
> [Alex Plits]
> We have configured --enable-pshared on xenomai 3.0.2 and now compiling empty application (just empty main routine) using non posix skin e.g. vxworks or even alchemy causes the
> "Bus error" in runtime(see below). Removing --enable-pshared bootstrap completes successfully.
>
> # ./posixvx --trace=1
> -- xenomai_init() running
> -- cobalt->init()
> -- connected to Cobalt
> -- memory locked
> -- memory heaps mapped
> -- boilerplate->init()
> -- copperplate->init()
> Bus error
gdb backtrace?
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-25 10:38 ` Philippe Gerum
@ 2016-04-25 10:41 ` Philippe Gerum
2016-04-25 11:42 ` Alex Plits
2016-04-26 8:10 ` Alex Plits
0 siblings, 2 replies; 13+ messages in thread
From: Philippe Gerum @ 2016-04-25 10:41 UTC (permalink / raw)
To: Alex Plits, Gilles Chanteperdrix; +Cc: xenomai
On 04/25/2016 12:38 PM, Philippe Gerum wrote:
> On 04/25/2016 12:03 PM, Alex Plits wrote:
>>
>>
>>> -----Original Message-----
>>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>>> Sent: Thursday, April 07, 2016 8:56 PM
>>> To: Alex Plits; Gilles Chanteperdrix
>>> Cc: xenomai@xenomai.org
>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>>
>>> On 04/07/2016 07:56 AM, Alex Plits wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>>>>> Sent: Tuesday, April 05, 2016 10:03 AM
>>>>> To: Alex Plits
>>>>> Cc: xenomai@xenomai.org
>>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>>>>
>>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We are currently porting some of our vxWorks xenomai (copperplate)
>>>>>> APIs we use in our application to Posix (cobalt I guess).
>>>>>
>>>>> Well, if you do not know whether you are using Cobalt or Mercury, we
>>>>> can not know it for you...
>>>> [Alex Plits]
>>>> Cobalt :)
>>>>>
>>>>>> We have started with the VxWorks "tasks" but it seems that we're
>>>>>> getting strange behavior on The remaining VxWorks APIs when used
>>>>>> from
>>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
>>>>> MsqQRecv function gets segfault but when it is used From a VxWorks
>>>>> generated task it works fine.
>>>>>> I understand from the comments in code it should work but I was
>>>>> wondering if there are known issues.
>>>>>>
>>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
>>>>>> xenomai
>>>>> 3.0.2).
>>>>>
>>>>> Could you send a self-contained, simplest possible test case which
>>>>> causes the problem for you, that we can test on the latest Xenomai
>>>>> release to see if the problem has not been already fixed?
>>>>>
>>>> [Alex Plits]
>>>> Attached code that is ripped from xenomai examples and initiates 2
>>> threads using posix api then uses VxWorks MsgQ to communicate.
>>>> Please advise if this code works as expected - it seems that when we use
>>> WAIT_FOREVER flag we have an issue.
>>>>
>>>> Sorry in advance for the #ifdef's and comments in code -
>>>
>>> For the record, 3.0-rc6 won't work properly with --enable-pshared setups.
>>> For sane shared processing involving multiple copperplate-based APIs (such
>>> as VxWorks), you do need 3.0.2.
>> [Alex Plits]
>> We have configured --enable-pshared on xenomai 3.0.2 and now compiling empty application (just empty main routine) using non posix skin e.g. vxworks or even alchemy causes the
>> "Bus error" in runtime(see below). Removing --enable-pshared bootstrap completes successfully.
>>
>> # ./posixvx --trace=1
>> -- xenomai_init() running
>> -- cobalt->init()
>> -- connected to Cobalt
>> -- memory locked
>> -- memory heaps mapped
>> -- boilerplate->init()
>> -- copperplate->init()
>> Bus error
>
> gdb backtrace?
>
>
The output of posixvx --dump-config is needed as well.
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-25 10:41 ` Philippe Gerum
@ 2016-04-25 11:42 ` Alex Plits
2016-04-26 8:10 ` Alex Plits
1 sibling, 0 replies; 13+ messages in thread
From: Alex Plits @ 2016-04-25 11:42 UTC (permalink / raw)
To: Philippe Gerum, Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Monday, April 25, 2016 1:42 PM
> To: Alex Plits; Gilles Chanteperdrix
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
> On 04/25/2016 12:38 PM, Philippe Gerum wrote:
> > On 04/25/2016 12:03 PM, Alex Plits wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Philippe Gerum [mailto:rpm@xenomai.org]
> >>> Sent: Thursday, April 07, 2016 8:56 PM
> >>> To: Alex Plits; Gilles Chanteperdrix
> >>> Cc: xenomai@xenomai.org
> >>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>
> >>> On 04/07/2016 07:56 AM, Alex Plits wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Gilles Chanteperdrix
> >>>>> [mailto:gilles.chanteperdrix@xenomai.org]
> >>>>> Sent: Tuesday, April 05, 2016 10:03 AM
> >>>>> To: Alex Plits
> >>>>> Cc: xenomai@xenomai.org
> >>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>>>
> >>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> We are currently porting some of our vxWorks xenomai
> >>>>>> (copperplate) APIs we use in our application to Posix (cobalt I guess).
> >>>>>
> >>>>> Well, if you do not know whether you are using Cobalt or Mercury,
> >>>>> we can not know it for you...
> >>>> [Alex Plits]
> >>>> Cobalt :)
> >>>>>
> >>>>>> We have started with the VxWorks "tasks" but it seems that we're
> >>>>>> getting strange behavior on The remaining VxWorks APIs when used
> >>>>>> from
> >>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
> >>>>> MsqQRecv function gets segfault but when it is used From a VxWorks
> >>>>> generated task it works fine.
> >>>>>> I understand from the comments in code it should work but I was
> >>>>> wondering if there are known issues.
> >>>>>>
> >>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
> >>>>>> xenomai
> >>>>> 3.0.2).
> >>>>>
> >>>>> Could you send a self-contained, simplest possible test case which
> >>>>> causes the problem for you, that we can test on the latest Xenomai
> >>>>> release to see if the problem has not been already fixed?
> >>>>>
> >>>> [Alex Plits]
> >>>> Attached code that is ripped from xenomai examples and initiates 2
> >>> threads using posix api then uses VxWorks MsgQ to communicate.
> >>>> Please advise if this code works as expected - it seems that when
> >>>> we use
> >>> WAIT_FOREVER flag we have an issue.
> >>>>
> >>>> Sorry in advance for the #ifdef's and comments in code -
> >>>
> >>> For the record, 3.0-rc6 won't work properly with --enable-pshared
> setups.
> >>> For sane shared processing involving multiple copperplate-based APIs
> >>> (such as VxWorks), you do need 3.0.2.
> >> [Alex Plits]
> >> We have configured --enable-pshared on xenomai 3.0.2 and now
> >> compiling empty application (just empty main routine) using non posix
> skin e.g. vxworks or even alchemy causes the "Bus error" in runtime(see
> below). Removing --enable-pshared bootstrap completes successfully.
> >>
> >> # ./posixvx --trace=1
> >> -- xenomai_init() running
> >> -- cobalt->init()
> >> -- connected to Cobalt
> >> -- memory locked
> >> -- memory heaps mapped
> >> -- boilerplate->init()
> >> -- copperplate->init()
> >> Bus error
> >
> > gdb backtrace?
> >
> >
>
> The output of posixvx --dump-config is needed as well.
[Alex Plits]
See below --dump-config , working to get the gdb backtrace.
# ./posixvx
Bus error
# ./posixvx --dump-config
based on Xenomai/cobalt v3.0.2
CONFIG_MMU=1
CONFIG_SMP=1
CONFIG_XENO_BUILD_ARGS=" '--target=arm-openwrt-linux' '--host=arm-openwrt-linux' '--build=x86_64-linux-gnu' '--program-prefix=' '--program-suffix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc' '--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man' '--infodir=/usr/info' '--disable-nls' '--with-core=cobalt' '--enable-smp' '--enable-lores-clock' '--enable-pshared' 'build_alias=x86_64-linux-gnu' 'host_alias=arm-openwrt-linux' 'target_alias=arm-openwrt-linux' 'CC=arm-openwrt-linux-uclibcgnueabi-gcc' 'CFLAGS=-Os -pipe -march=armv7-a -mtune=cortex-a7 -fno-caller-saves -fstack-protector -Wl,-z,relro,-z,now -fhonour-copts -Wno-error=unused-but-set-variable -mfloat-abi=soft ' 'LDFLAGS=-L/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/lib -L/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/lib -Wl,-z,relro,-z,now -L/media/HD/SDK/PLATFORM/SDK/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/usr/lib -L/media/HD/SDK/PLATFORM/SDK/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/lib ' 'CPPFLAGS=-I/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/include -I/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/include -I/media/HD/SDK/PLATFORM/SDK/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/usr/include -I/media/HD/SDK/PLATFORM/SDK/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include ' 'PKG_CONFIG=/media/HD/SDK/PLATFORM/SDK/staging_dir/host/bin/pkg-config' 'PKG_CONFIG_PATH=/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/lib/pkgconfig:/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/share/pkgconfig' 'PKG_CONFIG_LIBDIR=/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/lib/pkgconfig:/media/HD/SDK/PLATFORM/SDK/staging_dir/target-arm_cortex-a7_uClibc-0.9.33.2_eabi/usr/share/pkgconfig'"
CONFIG_XENO_BUILD_STRING="x86_64-pc-linux-gnu"
CONFIG_XENO_COBALT=1
CONFIG_XENO_COMPILER="gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.01 r43761) "
CONFIG_XENO_DEFAULT_PERIOD=1000000
CONFIG_XENO_HOST_STRING="arm-openwrt-linux-gnu"
CONFIG_XENO_PREFIX="/usr"
CONFIG_XENO_PSHARED=1
CONFIG_XENO_RAW_CLOCK_ENABLED=1
CONFIG_XENO_REVISION_LEVEL=2
CONFIG_XENO_SANITY=1
CONFIG_XENO_TLSF=1
CONFIG_XENO_TLS_MODEL="initial-exec"
CONFIG_XENO_UAPI_LEVEL=14
CONFIG_XENO_VERSION_MAJOR=3
CONFIG_XENO_VERSION_MINOR=0
CONFIG_XENO_VERSION_NAME="Exact Zero"
CONFIG_XENO_VERSION_STRING="3.0.2"
CONFIG_XENO_X86_VSYSCALL=1
---
CONFIG_XENO_ASYNC_CANCEL is OFF
CONFIG_XENO_COPPERPLATE_CLOCK_RESTRICTED is OFF
CONFIG_XENO_DEBUG is OFF
CONFIG_XENO_DEBUG_FULL is OFF
CONFIG_XENO_FORTIFY is OFF
CONFIG_XENO_LIBS_DLOPEN is OFF
CONFIG_XENO_LORES_CLOCK_DISABLED is OFF
CONFIG_XENO_MERCURY is OFF
CONFIG_XENO_REGISTRY is OFF
CONFIG_XENO_REGISTRY_ROOT is OFF
CONFIG_XENO_VALGRIND_API is OFF
CONFIG_XENO_WORKAROUND_CONDVAR_PI is OFF
---
PTHREAD_STACK_DEFAULT=65536
>
> --
> Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-25 10:41 ` Philippe Gerum
2016-04-25 11:42 ` Alex Plits
@ 2016-04-26 8:10 ` Alex Plits
2016-05-02 19:17 ` Philippe Gerum
1 sibling, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-04-26 8:10 UTC (permalink / raw)
To: Philippe Gerum, Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Monday, April 25, 2016 1:42 PM
> To: Alex Plits; Gilles Chanteperdrix
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
> On 04/25/2016 12:38 PM, Philippe Gerum wrote:
> > On 04/25/2016 12:03 PM, Alex Plits wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Philippe Gerum [mailto:rpm@xenomai.org]
> >>> Sent: Thursday, April 07, 2016 8:56 PM
> >>> To: Alex Plits; Gilles Chanteperdrix
> >>> Cc: xenomai@xenomai.org
> >>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>
> >>> On 04/07/2016 07:56 AM, Alex Plits wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Gilles Chanteperdrix
> >>>>> [mailto:gilles.chanteperdrix@xenomai.org]
> >>>>> Sent: Tuesday, April 05, 2016 10:03 AM
> >>>>> To: Alex Plits
> >>>>> Cc: xenomai@xenomai.org
> >>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>>>
> >>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> We are currently porting some of our vxWorks xenomai
> >>>>>> (copperplate) APIs we use in our application to Posix (cobalt I guess).
> >>>>>
> >>>>> Well, if you do not know whether you are using Cobalt or Mercury,
> >>>>> we can not know it for you...
> >>>> [Alex Plits]
> >>>> Cobalt :)
> >>>>>
> >>>>>> We have started with the VxWorks "tasks" but it seems that we're
> >>>>>> getting strange behavior on The remaining VxWorks APIs when used
> >>>>>> from
> >>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
> >>>>> MsqQRecv function gets segfault but when it is used From a VxWorks
> >>>>> generated task it works fine.
> >>>>>> I understand from the comments in code it should work but I was
> >>>>> wondering if there are known issues.
> >>>>>>
> >>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
> >>>>>> xenomai
> >>>>> 3.0.2).
> >>>>>
> >>>>> Could you send a self-contained, simplest possible test case which
> >>>>> causes the problem for you, that we can test on the latest Xenomai
> >>>>> release to see if the problem has not been already fixed?
> >>>>>
> >>>> [Alex Plits]
> >>>> Attached code that is ripped from xenomai examples and initiates 2
> >>> threads using posix api then uses VxWorks MsgQ to communicate.
> >>>> Please advise if this code works as expected - it seems that when
> >>>> we use
> >>> WAIT_FOREVER flag we have an issue.
> >>>>
> >>>> Sorry in advance for the #ifdef's and comments in code -
> >>>
> >>> For the record, 3.0-rc6 won't work properly with --enable-pshared
> setups.
> >>> For sane shared processing involving multiple copperplate-based APIs
> >>> (such as VxWorks), you do need 3.0.2.
> >> [Alex Plits]
> >> We have configured --enable-pshared on xenomai 3.0.2 and now
> >> compiling empty application (just empty main routine) using non posix
> skin e.g. vxworks or even alchemy causes the "Bus error" in runtime(see
> below). Removing --enable-pshared bootstrap completes successfully.
> >>
> >> # ./posixvx --trace=1
> >> -- xenomai_init() running
> >> -- cobalt->init()
> >> -- connected to Cobalt
> >> -- memory locked
> >> -- memory heaps mapped
> >> -- boilerplate->init()
> >> -- copperplate->init()
> >> Bus error
> >
> > gdb backtrace?
> >
> >
[Alex Plits]
We're not getting the symbols correctly although everything seems to be in place (debugging info, correct symbol file loaded etc.)
According to the following memory mapping dump and gdb address backtrace it seems the issue is in cooperplate but again we can't seem
to find the corresponding symbol/function.
GDB
#0 0xb6fc455c in ?? ()
Cannot access memory at address 0x6e6f6e58
Memory Mapping
00008000-00009000 r-xp 00000000 00:0c 4841 /tmp/posixvx
00010000-00011000 r--p 00000000 00:0c 4841 /tmp/posixvx
00011000-00012000 rw-p 00001000 00:0c 4841 /tmp/posixvx
00012000-00013000 rw-p 00000000 00:00 0 [heap]
b6e27000-b6e2a000 r-xp 00000000 00:01 2556 /lib/libdl-0.9.33.2.so
b6e2a000-b6e31000 ---p 00000000 00:00 0
b6e31000-b6e32000 r--p 00002000 00:01 2556 /lib/libdl-0.9.33.2.so
b6e32000-b6e33000 rw-p 00003000 00:01 2556 /lib/libdl-0.9.33.2.so
b6e33000-b6e7a000 r-xp 00000000 00:01 2941 /lib/libuClibc-0.9.33.2.so
b6e7a000-b6e82000 ---p 00000000 00:00 0
b6e82000-b6e83000 r--p 00047000 00:01 2941 /lib/libuClibc-0.9.33.2.so
b6e83000-b6e84000 rw-p 00048000 00:01 2941 /lib/libuClibc-0.9.33.2.so
b6e84000-b6e88000 rw-p 00000000 00:00 0
b6e88000-b6e93000 r-xp 00000000 00:01 2621 /lib/libgcc_s.so.1
b6e93000-b6e9b000 ---p 00000000 00:00 0
b6e9b000-b6e9c000 r--p 0000b000 00:01 2621 /lib/libgcc_s.so.1
b6e9c000-b6e9d000 rw-p 0000c000 00:01 2621 /lib/libgcc_s.so.1
b6e9d000-b6eab000 r-xp 00000000 00:01 2942 /lib/libm-0.9.33.2.so
b6eab000-b6eb3000 ---p 00000000 00:00 0
b6eb3000-b6eb4000 r--p 0000e000 00:01 2942 /lib/libm-0.9.33.2.so
b6eb4000-b6eb5000 rw-p 0000f000 00:01 2942 /lib/libm-0.9.33.2.so
b6eb5000-b6f4e000 r-xp 00000000 00:01 1248 /usr/lib/libstdc++.so.6.0.19
b6f4e000-b6f55000 ---p 00000000 00:00 0
b6f55000-b6f59000 r--p 00098000 00:01 1248 /usr/lib/libstdc++.so.6.0.19
b6f59000-b6f5b000 rw-p 0009c000 00:01 1248 /usr/lib/libstdc++.so.6.0.19
b6f5b000-b6f62000 rw-p 00000000 00:00 0
b6f62000-b6f72000 r-xp 00000000 00:01 1185 /usr/lib/libz.so.1.2.8
b6f72000-b6f73000 r--p 00010000 00:01 1185 /usr/lib/libz.so.1.2.8
b6f73000-b6f74000 rw-p 00011000 00:01 1185 /usr/lib/libz.so.1.2.8
b6f74000-b6f7c000 r-xp 00000000 00:01 494 /usr/lib/libvxworks.so.0.0.0
b6f7c000-b6f83000 ---p 00000000 00:00 0
b6f83000-b6f84000 r--p 00007000 00:01 494 /usr/lib/libvxworks.so.0.0.0
b6f84000-b6f85000 rw-p 00008000 00:01 494 /usr/lib/libvxworks.so.0.0.0
b6f85000-b6f88000 r-xp 00000000 00:01 2610 /lib/librt-0.9.33.2.so
b6f88000-b6f8f000 ---p 00000000 00:00 0
b6f8f000-b6f90000 r--p 00002000 00:01 2610 /lib/librt-0.9.33.2.so
b6f90000-b6f91000 rw-p 00003000 00:01 2610 /lib/librt-0.9.33.2.so
b6f91000-b6fa1000 r-xp 00000000 00:01 2622 /lib/libpthread-0.9.33.2.so
b6fa1000-b6fa8000 ---p 00000000 00:00 0
b6fa8000-b6fa9000 r--p 0000f000 00:01 2622 /lib/libpthread-0.9.33.2.so
b6fa9000-b6faa000 rw-p 00010000 00:01 2622 /lib/libpthread-0.9.33.2.so
b6faa000-b6fac000 rw-p 00000000 00:00 0
b6fac000-b6faf000 r-xp 00000000 00:01 498 /usr/lib/libffi.so.6.0.0
b6faf000-b6fb6000 ---p 00000000 00:00 0
b6fb6000-b6fb7000 r--p 00002000 00:01 498 /usr/lib/libffi.so.6.0.0
b6fb7000-b6fb8000 rw-p 00003000 00:01 498 /usr/lib/libffi.so.6.0.0
b6fb8000-b6fc7000 r-xp 00000000 00:01 1688 /usr/lib/libcopperplate.so.0.0.0
b6fc7000-b6fce000 ---p 00000000 00:00 0
b6fce000-b6fcf000 r--p 0000e000 00:01 1688 /usr/lib/libcopperplate.so.0.0.0
b6fcf000-b6fd0000 rw-p 0000f000 00:01 1688 /usr/lib/libcopperplate.so.0.0.0
b6fd0000-b6fe7000 r-xp 00000000 00:01 513 /usr/lib/libcobalt.so.2.0.0
b6fe7000-b6fef000 ---p 00000000 00:00 0
b6fef000-b6ff0000 r--p 00017000 00:01 513 /usr/lib/libcobalt.so.2.0.0
b6ff0000-b6ff1000 rw-p 00018000 00:01 513 /usr/lib/libcobalt.so.2.0.0
b6ff1000-b6ff7000 r-xp 00000000 00:01 2607 /lib/ld-uClibc-0.9.33.2.so
b6ffa000-b6ffd000 rw-p 00000000 00:00 0
b6ffd000-b6ffe000 r-xp 00000000 00:00 0 [sigpage]
b6ffe000-b6fff000 r--p 00005000 00:01 2607 /lib/ld-uClibc-0.9.33.2.so
b6fff000-b7000000 rw-p 00006000 00:01 2607 /lib/ld-uClibc-0.9.33.2.so
befdf000-bf000000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
>
> The output of posixvx --dump-config is needed as well.
>
> --
> Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-04-26 8:10 ` Alex Plits
@ 2016-05-02 19:17 ` Philippe Gerum
2016-05-03 13:06 ` Alex Plits
0 siblings, 1 reply; 13+ messages in thread
From: Philippe Gerum @ 2016-05-02 19:17 UTC (permalink / raw)
To: Alex Plits, Gilles Chanteperdrix; +Cc: xenomai
On 04/26/2016 10:10 AM, Alex Plits wrote:
>
>
>> -----Original Message-----
>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>> Sent: Monday, April 25, 2016 1:42 PM
>> To: Alex Plits; Gilles Chanteperdrix
>> Cc: xenomai@xenomai.org
>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>
>> On 04/25/2016 12:38 PM, Philippe Gerum wrote:
>>> On 04/25/2016 12:03 PM, Alex Plits wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>>>>> Sent: Thursday, April 07, 2016 8:56 PM
>>>>> To: Alex Plits; Gilles Chanteperdrix
>>>>> Cc: xenomai@xenomai.org
>>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>>>>
>>>>> On 04/07/2016 07:56 AM, Alex Plits wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Gilles Chanteperdrix
>>>>>>> [mailto:gilles.chanteperdrix@xenomai.org]
>>>>>>> Sent: Tuesday, April 05, 2016 10:03 AM
>>>>>>> To: Alex Plits
>>>>>>> Cc: xenomai@xenomai.org
>>>>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>>>>>>>
>>>>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We are currently porting some of our vxWorks xenomai
>>>>>>>> (copperplate) APIs we use in our application to Posix (cobalt I guess).
>>>>>>>
>>>>>>> Well, if you do not know whether you are using Cobalt or Mercury,
>>>>>>> we can not know it for you...
>>>>>> [Alex Plits]
>>>>>> Cobalt :)
>>>>>>>
>>>>>>>> We have started with the VxWorks "tasks" but it seems that we're
>>>>>>>> getting strange behavior on The remaining VxWorks APIs when used
>>>>>>>> from
>>>>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
>>>>>>> MsqQRecv function gets segfault but when it is used From a VxWorks
>>>>>>> generated task it works fine.
>>>>>>>> I understand from the comments in code it should work but I was
>>>>>>> wondering if there are known issues.
>>>>>>>>
>>>>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
>>>>>>>> xenomai
>>>>>>> 3.0.2).
>>>>>>>
>>>>>>> Could you send a self-contained, simplest possible test case which
>>>>>>> causes the problem for you, that we can test on the latest Xenomai
>>>>>>> release to see if the problem has not been already fixed?
>>>>>>>
>>>>>> [Alex Plits]
>>>>>> Attached code that is ripped from xenomai examples and initiates 2
>>>>> threads using posix api then uses VxWorks MsgQ to communicate.
>>>>>> Please advise if this code works as expected - it seems that when
>>>>>> we use
>>>>> WAIT_FOREVER flag we have an issue.
>>>>>>
>>>>>> Sorry in advance for the #ifdef's and comments in code -
>>>>>
>>>>> For the record, 3.0-rc6 won't work properly with --enable-pshared
>> setups.
>>>>> For sane shared processing involving multiple copperplate-based APIs
>>>>> (such as VxWorks), you do need 3.0.2.
>>>> [Alex Plits]
>>>> We have configured --enable-pshared on xenomai 3.0.2 and now
>>>> compiling empty application (just empty main routine) using non posix
>> skin e.g. vxworks or even alchemy causes the "Bus error" in runtime(see
>> below). Removing --enable-pshared bootstrap completes successfully.
>>>>
>>>> # ./posixvx --trace=1
>>>> -- xenomai_init() running
>>>> -- cobalt->init()
>>>> -- connected to Cobalt
>>>> -- memory locked
>>>> -- memory heaps mapped
>>>> -- boilerplate->init()
>>>> -- copperplate->init()
>>>> Bus error
>>>
>>> gdb backtrace?
>>>
>>>
> [Alex Plits]
> We're not getting the symbols correctly although everything seems to be in place (debugging info, correct symbol file loaded etc.)
> According to the following memory mapping dump and gdb address backtrace it seems the issue is in cooperplate but again we can't seem
> to find the corresponding symbol/function.
>
> GDB
> #0 0xb6fc455c in ?? ()
> Cannot access memory at address 0x6e6f6e58
>
This looks like a random ascii sequence ("nonX"), not a valid pointer.
Can you strace this executable?
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-05-02 19:17 ` Philippe Gerum
@ 2016-05-03 13:06 ` Alex Plits
2016-05-11 6:59 ` Alex Plits
0 siblings, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-05-03 13:06 UTC (permalink / raw)
To: Philippe Gerum, Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Monday, May 02, 2016 10:18 PM
> To: Alex Plits; Gilles Chanteperdrix
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
> On 04/26/2016 10:10 AM, Alex Plits wrote:
> >
> >
> >> -----Original Message-----
> >> From: Philippe Gerum [mailto:rpm@xenomai.org]
> >> Sent: Monday, April 25, 2016 1:42 PM
> >> To: Alex Plits; Gilles Chanteperdrix
> >> Cc: xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>
> >> On 04/25/2016 12:38 PM, Philippe Gerum wrote:
> >>> On 04/25/2016 12:03 PM, Alex Plits wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Philippe Gerum [mailto:rpm@xenomai.org]
> >>>>> Sent: Thursday, April 07, 2016 8:56 PM
> >>>>> To: Alex Plits; Gilles Chanteperdrix
> >>>>> Cc: xenomai@xenomai.org
> >>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>>>
> >>>>> On 04/07/2016 07:56 AM, Alex Plits wrote:
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Gilles Chanteperdrix
> >>>>>>> [mailto:gilles.chanteperdrix@xenomai.org]
> >>>>>>> Sent: Tuesday, April 05, 2016 10:03 AM
> >>>>>>> To: Alex Plits
> >>>>>>> Cc: xenomai@xenomai.org
> >>>>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >>>>>>>
> >>>>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> We are currently porting some of our vxWorks xenomai
> >>>>>>>> (copperplate) APIs we use in our application to Posix (cobalt I
> guess).
> >>>>>>>
> >>>>>>> Well, if you do not know whether you are using Cobalt or
> >>>>>>> Mercury, we can not know it for you...
> >>>>>> [Alex Plits]
> >>>>>> Cobalt :)
> >>>>>>>
> >>>>>>>> We have started with the VxWorks "tasks" but it seems that
> >>>>>>>> we're getting strange behavior on The remaining VxWorks APIs
> >>>>>>>> when used from
> >>>>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
> >>>>>>> MsqQRecv function gets segfault but when it is used From a
> >>>>>>> VxWorks generated task it works fine.
> >>>>>>>> I understand from the comments in code it should work but I was
> >>>>>>> wondering if there are known issues.
> >>>>>>>>
> >>>>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes
> >>>>>>>> in xenomai
> >>>>>>> 3.0.2).
> >>>>>>>
> >>>>>>> Could you send a self-contained, simplest possible test case
> >>>>>>> which causes the problem for you, that we can test on the latest
> >>>>>>> Xenomai release to see if the problem has not been already fixed?
> >>>>>>>
> >>>>>> [Alex Plits]
> >>>>>> Attached code that is ripped from xenomai examples and initiates
> >>>>>> 2
> >>>>> threads using posix api then uses VxWorks MsgQ to communicate.
> >>>>>> Please advise if this code works as expected - it seems that
> >>>>>> when we use
> >>>>> WAIT_FOREVER flag we have an issue.
> >>>>>>
> >>>>>> Sorry in advance for the #ifdef's and comments in code -
> >>>>>
> >>>>> For the record, 3.0-rc6 won't work properly with --enable-pshared
> >> setups.
> >>>>> For sane shared processing involving multiple copperplate-based
> >>>>> APIs (such as VxWorks), you do need 3.0.2.
> >>>> [Alex Plits]
> >>>> We have configured --enable-pshared on xenomai 3.0.2 and now
> >>>> compiling empty application (just empty main routine) using non
> >>>> posix
> >> skin e.g. vxworks or even alchemy causes the "Bus error" in
> >> runtime(see below). Removing --enable-pshared bootstrap completes
> successfully.
> >>>>
> >>>> # ./posixvx --trace=1
> >>>> -- xenomai_init() running
> >>>> -- cobalt->init()
> >>>> -- connected to Cobalt
> >>>> -- memory locked
> >>>> -- memory heaps mapped
> >>>> -- boilerplate->init()
> >>>> -- copperplate->init()
> >>>> Bus error
> >>>
> >>> gdb backtrace?
> >>>
> >>>
> > [Alex Plits]
> > We're not getting the symbols correctly although everything seems to
> > be in place (debugging info, correct symbol file loaded etc.)
> > According to the following memory mapping dump and gdb address
> backtrace it seems the issue is in cooperplate but again we can't seem to find
> the corresponding symbol/function.
> >
> > GDB
> > #0 0xb6fc455c in ?? ()
> > Cannot access memory at address 0x6e6f6e58
> >
>
> This looks like a random ascii sequence ("nonX"), not a valid pointer.
> Can you strace this executable?
>
[Alex Plits]
Sure. See below
# strace ./posixvx
execve("./posixvx", ["./posixvx"], [/* 7 vars */]) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb2000
stat("/etc/ld.so.cache", 0xbebf3b10) = -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=90595, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0t\214\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 126976, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f88000
mmap2(0xb6f88000, 87052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f88000
mmap2(0xb6fa5000, 4579, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x15) = 0xb6fa5000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libcopperplate.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libcopperplate.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=36951, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\264?\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 73728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f76000
mmap2(0xb6f76000, 33820, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f76000
mmap2(0xb6f86000, 4183, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8) = 0xb6f86000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libffi.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libffi.so.6", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12290, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\270\r\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f6a000
mmap2(0xb6f6a000, 9108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f6a000
mmap2(0xb6f74000, 4098, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6f74000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260C\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 110592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f4f000
mmap2(0xb6f4f000, 64160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f4f000
mmap2(0xb6f66000, 4123, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xf) = 0xb6f66000
mmap2(0xb6f68000, 4328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f68000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/librt.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0`\16\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f43000
mmap2(0xb6f43000, 8260, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f43000
mmap2(0xb6f4d000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6f4d000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libvxworks.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libvxworks.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=28729, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0H)\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f33000
mmap2(0xb6f33000, 24768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f33000
mmap2(0xb6f41000, 4153, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x6) = 0xb6f41000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libz.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=69693, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320\25\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 73728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f21000
mmap2(0xb6f21000, 65348, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f21000
mmap2(0xb6f31000, 4157, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10) = 0xb6f31000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=645079, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\244u\4\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 708608, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6e74000
mmap2(0xb6e74000, 623772, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e74000
mmap2(0xb6f14000, 22487, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x98) = 0xb6f14000
mmap2(0xb6f1a000, 25420, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f1a000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libm.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=61444, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0<\23\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 98304, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6e5c000
mmap2(0xb6e5c000, 57247, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e5c000
mmap2(0xb6e72000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe) = 0xb6e72000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0000=\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 86016, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6e47000
mmap2(0xb6e47000, 44656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e47000
mmap2(0xb6e5a000, 4099, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb) = 0xb6e5a000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\237\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 348160, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6df2000
mmap2(0xb6df2000, 290708, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6df2000
mmap2(0xb6e41000, 4867, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x47) = 0xb6e41000
mmap2(0xb6e43000, 14576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e43000
close(3) = 0
munmap(0xb6fb1000, 4096) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=24581, ...}) = 0
open("/lib/librt.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
close(3) = 0
open("/lib/librt.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libdl.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12301, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb0000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0H\v\0\0004\0\0\0"..., 4096) = 4096
mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6de6000
mmap2(0xb6de6000, 8523, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6de6000
mmap2(0xb6df0000, 4109, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6df0000
close(3) = 0
munmap(0xb6fb0000, 4096) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libdl.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=12301, ...}) = 0
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libm.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=61444, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb0000
set_tls(0xb6fb0430, 0xb6fb0ae0, 0xb6fb0ae8, 0xb6fb0430, 0xb6fb4f74) = 0
gettimeofday({1462279873, 50496}, NULL) = 0
mprotect(0x11000, 4096, PROT_READ) = 0
mprotect(0xb6fa5000, 4096, PROT_READ) = 0
mprotect(0xb6f86000, 4096, PROT_READ) = 0
mprotect(0xb6f74000, 4096, PROT_READ) = 0
mprotect(0xb6f66000, 4096, PROT_READ) = 0
mprotect(0xb6f4d000, 4096, PROT_READ) = 0
mprotect(0xb6f41000, 4096, PROT_READ) = 0
mprotect(0xb6f31000, 4096, PROT_READ) = 0
mprotect(0xb6f14000, 16384, PROT_READ) = 0
mprotect(0xb6e72000, 4096, PROT_READ) = 0
mprotect(0xb6e5a000, 4096, PROT_READ) = 0
mprotect(0xb6e41000, 4096, PROT_READ) = 0
mprotect(0xb6fb4000, 4096, PROT_READ) = 0
mprotect(0xb6df0000, 4096, PROT_READ) = 0
set_tid_address(0xb6fb0068) = 1951
set_robust_list(0xb6fb0070, 12) = 0
rt_sigaction(SIGRTMIN, {0xb6f57730, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb6f575f0, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
brk(0) = 0x37b000
brk(0x37c000) = 0x37c000
write(1, "init Xenomai\n", 13init Xenomai
) = 13
gettid() = 1951
rt_sigaction(SIGILL, {0xb6f921e8, [ILL], SA_RESTART|0x4000000}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL, [ILL], SA_RESTART|0x4000000}, {0xb6f921e8, [ILL], SA_RESTART|0x4000000}, 8) = 0
mlockall(MCL_CURRENT|MCL_FUTURE) = 0
open("/dev/mem", O_RDONLY|O_SYNC) = 3
mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 3, 0) = 0xb6fae000
close(3) = 0
futex(0xb6fa634c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb6fa61f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
rt_sigaction(SIGXCPU, {0xb6f92be8, [], SA_SIGINFO|0x4000000}, {SIG_DFL, [], 0}, 8) = 0
brk(0x38c000) = 0x38c000
mmap2(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6bc6000
mprotect(0xb6bc6000, 4096, PROT_NONE) = 0
clone(child_stack=0xb6dc50e8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6dc5588, tls=0xb6dc5950, child_tidptr=0xb6dc5588) = 1952
sched_getparam(1951, { 0 }) = 0
sched_getscheduler(1951) = 0 (SCHED_OTHER)
sched_get_priority_max(SCHED_FIFO) = 99
sched_setscheduler(1951, SCHED_OTHER, { 0 }) = 0
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
rt_sigaction(SIGWINCH, {0xb6f96550, [], SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xb6fa62c4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6bc3000
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ac2000
geteuid32() = 0
open("/etc/passwd", O_RDONLY) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0xbebf3acc) = -1 ENOTTY (Inappropriate ioctl for device)
brk(0x38d000) = 0x38d000
read(3, "root:x:0:0:root:/root:/bin/ash\nd"..., 4096) = 190
close(3) = 0
prctl(PR_GET_NAME, 0xb6bc3d04, 0, 0, 0) = 0
gettid() = 1951
write(1, "Create msgQ\n", 12Create msgQ
) = 12
write(1, "start server\n", 13start server
) = 13
sched_getaffinity(1951, 128, {1}) = 4
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6ab2000
mprotect(0xb6ab2000, 4096, PROT_NONE) = 0
clone(child_stack=0xb6ac10e8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6ac1588, tls=0xb6ac1950, child_tidptr=0xb6ac1588) = 1953
sched_setaffinity(1953, 128, {2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}) = 0
futex(0xb6ac1734, FUTEX_WAKE_PRIVATE, 1) = 1
clock_gettime(CLOCK_REALTIME, {1462279873, 549992977}) = 0
write(1, "server is up\n", 13server is up
) = 13
write(1, "start sender\n", 13start sender
) = 13
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6aa2000
mprotect(0xb6aa2000, 4096, PROT_NONE) = 0
clone(child_stack=0xb6ab10e8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6ab1588, tls=0xb6ab1950, child_tidptr=0xb6ab1588) = 1954
clock_gettime(CLOCK_REALTIME, {1462279873, 555642310}) = 0
gettimeofday({1462279873, 556216}, NULL) = 0
futex(0xbebf3b78, FUTEX_WAIT_PRIVATE, 0, {4, 443784000}) = 0
futex(0xb6ab1588, FUTEX_WAIT, 1954, NULLsender is up
send msg
<unfinished ...>
+++ killed by SIGSEGV +++
Segmentation fault
Thanks,
Alex Plits.
> --
> Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-05-03 13:06 ` Alex Plits
@ 2016-05-11 6:59 ` Alex Plits
2016-05-23 9:14 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Alex Plits @ 2016-05-11 6:59 UTC (permalink / raw)
To: Philippe Gerum, Gilles Chanteperdrix; +Cc: xenomai
> -----Original Message-----
> From: Alex Plits
> Sent: Tuesday, May 03, 2016 4:07 PM
> To: 'Philippe Gerum'; Gilles Chanteperdrix
> Cc: xenomai@xenomai.org
> Subject: RE: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
>
>
>
> > -----Original Message-----
> > From: Philippe Gerum [mailto:rpm@xenomai.org]
> > Sent: Monday, May 02, 2016 10:18 PM
> > To: Alex Plits; Gilles Chanteperdrix
> > Cc: xenomai@xenomai.org
> > Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >
> > On 04/26/2016 10:10 AM, Alex Plits wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Philippe Gerum [mailto:rpm@xenomai.org]
> > >> Sent: Monday, April 25, 2016 1:42 PM
> > >> To: Alex Plits; Gilles Chanteperdrix
> > >> Cc: xenomai@xenomai.org
> > >> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> > >>
> > >> On 04/25/2016 12:38 PM, Philippe Gerum wrote:
> > >>> On 04/25/2016 12:03 PM, Alex Plits wrote:
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Philippe Gerum [mailto:rpm@xenomai.org]
> > >>>>> Sent: Thursday, April 07, 2016 8:56 PM
> > >>>>> To: Alex Plits; Gilles Chanteperdrix
> > >>>>> Cc: xenomai@xenomai.org
> > >>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> > >>>>>
> > >>>>> On 04/07/2016 07:56 AM, Alex Plits wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Gilles Chanteperdrix
> > >>>>>>> [mailto:gilles.chanteperdrix@xenomai.org]
> > >>>>>>> Sent: Tuesday, April 05, 2016 10:03 AM
> > >>>>>>> To: Alex Plits
> > >>>>>>> Cc: xenomai@xenomai.org
> > >>>>>>> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> > >>>>>>>
> > >>>>>>> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> We are currently porting some of our vxWorks xenomai
> > >>>>>>>> (copperplate) APIs we use in our application to Posix (cobalt
> > >>>>>>>> I
> > guess).
> > >>>>>>>
> > >>>>>>> Well, if you do not know whether you are using Cobalt or
> > >>>>>>> Mercury, we can not know it for you...
> > >>>>>> [Alex Plits]
> > >>>>>> Cobalt :)
> > >>>>>>>
> > >>>>>>>> We have started with the VxWorks "tasks" but it seems that
> > >>>>>>>> we're getting strange behavior on The remaining VxWorks APIs
> > >>>>>>>> when used from
> > >>>>>>> the POSIX generated tasks (threads is the right word in posix) e.g.
> > >>>>>>> MsqQRecv function gets segfault but when it is used From a
> > >>>>>>> VxWorks generated task it works fine.
> > >>>>>>>> I understand from the comments in code it should work but I
> > >>>>>>>> was
> > >>>>>>> wondering if there are known issues.
> > >>>>>>>>
> > >>>>>>>> We are using currently xenomai 3 rc-6 (I saw there were fixes
> > >>>>>>>> in xenomai
> > >>>>>>> 3.0.2).
> > >>>>>>>
> > >>>>>>> Could you send a self-contained, simplest possible test case
> > >>>>>>> which causes the problem for you, that we can test on the
> > >>>>>>> latest Xenomai release to see if the problem has not been
> already fixed?
> > >>>>>>>
> > >>>>>> [Alex Plits]
> > >>>>>> Attached code that is ripped from xenomai examples and
> > >>>>>> initiates
> > >>>>>> 2
> > >>>>> threads using posix api then uses VxWorks MsgQ to communicate.
> > >>>>>> Please advise if this code works as expected - it seems that
> > >>>>>> when we use
> > >>>>> WAIT_FOREVER flag we have an issue.
> > >>>>>>
> > >>>>>> Sorry in advance for the #ifdef's and comments in code -
> > >>>>>
> > >>>>> For the record, 3.0-rc6 won't work properly with
> > >>>>> --enable-pshared
> > >> setups.
> > >>>>> For sane shared processing involving multiple copperplate-based
> > >>>>> APIs (such as VxWorks), you do need 3.0.2.
> > >>>> [Alex Plits]
> > >>>> We have configured --enable-pshared on xenomai 3.0.2 and now
> > >>>> compiling empty application (just empty main routine) using non
> > >>>> posix
> > >> skin e.g. vxworks or even alchemy causes the "Bus error" in
> > >> runtime(see below). Removing --enable-pshared bootstrap completes
> > successfully.
> > >>>>
> > >>>> # ./posixvx --trace=1
> > >>>> -- xenomai_init() running
> > >>>> -- cobalt->init()
> > >>>> -- connected to Cobalt
> > >>>> -- memory locked
> > >>>> -- memory heaps mapped
> > >>>> -- boilerplate->init()
> > >>>> -- copperplate->init()
> > >>>> Bus error
> > >>>
> > >>> gdb backtrace?
> > >>>
> > >>>
> > > [Alex Plits]
> > > We're not getting the symbols correctly although everything seems to
> > > be in place (debugging info, correct symbol file loaded etc.)
> > > According to the following memory mapping dump and gdb address
> > backtrace it seems the issue is in cooperplate but again we can't seem
> > to find the corresponding symbol/function.
> > >
> > > GDB
> > > #0 0xb6fc455c in ?? ()
> > > Cannot access memory at address 0x6e6f6e58
> > >
> >
> > This looks like a random ascii sequence ("nonX"), not a valid pointer.
> > Can you strace this executable?
> >
> [Alex Plits]
> Sure. See below
>
>
> # strace ./posixvx
> execve("./posixvx", ["./posixvx"], [/* 7 vars */]) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb2000
> stat("/etc/ld.so.cache", 0xbebf3b10) = -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=90595, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0t\214\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 126976, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f88000
> mmap2(0xb6f88000, 87052, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f88000
> mmap2(0xb6fa5000, 4579, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x15) = 0xb6fa5000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libcopperplate.so.0", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libcopperplate.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=36951, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\264?\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 73728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f76000
> mmap2(0xb6f76000, 33820, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f76000
> mmap2(0xb6f86000, 4183, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x8) = 0xb6f86000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libffi.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/lib/libffi.so.6", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12290, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\270\r\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f6a000
> mmap2(0xb6f6a000, 9108, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f6a000
> mmap2(0xb6f74000, 4098, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6f74000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libpthread.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260C\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 110592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f4f000
> mmap2(0xb6f4f000, 64160, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f4f000
> mmap2(0xb6f66000, 4123, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0xf) = 0xb6f66000
> mmap2(0xb6f68000, 4328, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f68000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/librt.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0`\16\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f43000
> mmap2(0xb6f43000, 8260, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f43000
> mmap2(0xb6f4d000, 4100, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6f4d000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libvxworks.so.0", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libvxworks.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=28729, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0H)\0\0004\0\0\0"..., 4096)
> = 4096
> mmap2(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f33000
> mmap2(0xb6f33000, 24768, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f33000
> mmap2(0xb6f41000, 4153, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x6) = 0xb6f41000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/lib/libz.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=69693, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320\25\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 73728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6f21000
> mmap2(0xb6f21000, 65348, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f21000
> mmap2(0xb6f31000, 4157, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x10) = 0xb6f31000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=645079, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\244u\4\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 708608, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6e74000
> mmap2(0xb6e74000, 623772, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e74000
> mmap2(0xb6f14000, 22487, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x98) = 0xb6f14000
> mmap2(0xb6f1a000, 25420, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f1a000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libm.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=61444, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0<\23\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 98304, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6e5c000
> mmap2(0xb6e5c000, 57247, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e5c000
> mmap2(0xb6e72000, 4100, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0xe) = 0xb6e72000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0000=\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 86016, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6e47000
> mmap2(0xb6e47000, 44656, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6e47000
> mmap2(0xb6e5a000, 4099, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0xb) = 0xb6e5a000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\237\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 348160, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6df2000
> mmap2(0xb6df2000, 290708, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6df2000
> mmap2(0xb6e41000, 4867, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x47) = 0xb6e41000
> mmap2(0xb6e43000, 14576, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e43000
> close(3) = 0
> munmap(0xb6fb1000, 4096) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb1000
> stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=24581, ...}) = 0
> open("/lib/librt.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
> close(3) = 0
> open("/lib/libpthread.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libpthread.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
> close(3) = 0
> open("/lib/librt.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12292, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libdl.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12301, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb0000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0H\v\0\0004\0\0\0"...,
> 4096) = 4096
> mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb6de6000
> mmap2(0xb6de6000, 8523, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6de6000
> mmap2(0xb6df0000, 4109, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0xb6df0000
> close(3) = 0
> munmap(0xb6fb0000, 4096) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libdl.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=12301, ...}) = 0
> close(3) = 0
> open("/lib/libpthread.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=65563, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libm.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=61444, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libgcc_s.so.1", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=49155, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> open("/lib/libc.so.0", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=295683, ...}) = 0
> close(3) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6fb0000
> set_tls(0xb6fb0430, 0xb6fb0ae0, 0xb6fb0ae8, 0xb6fb0430, 0xb6fb4f74) = 0
> gettimeofday({1462279873, 50496}, NULL) = 0
> mprotect(0x11000, 4096, PROT_READ) = 0
> mprotect(0xb6fa5000, 4096, PROT_READ) = 0
> mprotect(0xb6f86000, 4096, PROT_READ) = 0
> mprotect(0xb6f74000, 4096, PROT_READ) = 0
> mprotect(0xb6f66000, 4096, PROT_READ) = 0
> mprotect(0xb6f4d000, 4096, PROT_READ) = 0
> mprotect(0xb6f41000, 4096, PROT_READ) = 0
> mprotect(0xb6f31000, 4096, PROT_READ) = 0
> mprotect(0xb6f14000, 16384, PROT_READ) = 0
> mprotect(0xb6e72000, 4096, PROT_READ) = 0
> mprotect(0xb6e5a000, 4096, PROT_READ) = 0
> mprotect(0xb6e41000, 4096, PROT_READ) = 0
> mprotect(0xb6fb4000, 4096, PROT_READ) = 0
> mprotect(0xb6df0000, 4096, PROT_READ) = 0
> set_tid_address(0xb6fb0068) = 1951
> set_robust_list(0xb6fb0070, 12) = 0
> rt_sigaction(SIGRTMIN, {0xb6f57730, [], SA_SIGINFO|0x4000000}, NULL, 8) =
> 0
> rt_sigaction(SIGRT_1, {0xb6f575f0, [], SA_RESTART|SA_SIGINFO|0x4000000},
> NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) =
> 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost isig icanon echo ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B115200 opost isig icanon echo ...}) = 0
> brk(0) = 0x37b000
> brk(0x37c000) = 0x37c000
> write(1, "init Xenomai\n", 13init Xenomai
> ) = 13
> gettid() = 1951
> rt_sigaction(SIGILL, {0xb6f921e8, [ILL], SA_RESTART|0x4000000}, {SIG_DFL,
> [], 0}, 8) = 0
> rt_sigaction(SIGILL, {SIG_DFL, [ILL], SA_RESTART|0x4000000}, {0xb6f921e8,
> [ILL], SA_RESTART|0x4000000}, 8) = 0
> mlockall(MCL_CURRENT|MCL_FUTURE) = 0
> open("/dev/mem", O_RDONLY|O_SYNC) = 3
> mmap2(NULL, 4096, PROT_READ, MAP_SHARED, 3, 0) = 0xb6fae000
> close(3) = 0
> futex(0xb6fa634c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> futex(0xb6fa61f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> rt_sigaction(SIGXCPU, {0xb6f92be8, [], SA_SIGINFO|0x4000000}, {SIG_DFL,
> [], 0}, 8) = 0
> brk(0x38c000) = 0x38c000
> mmap2(NULL, 2097152, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6bc6000
> mprotect(0xb6bc6000, 4096, PROT_NONE) = 0
> clone(child_stack=0xb6dc50e8,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THRE
> AD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHIL
> D_CLEARTID, parent_tidptr=0xb6dc5588, tls=0xb6dc5950,
> child_tidptr=0xb6dc5588) = 1952
> sched_getparam(1951, { 0 }) = 0
> sched_getscheduler(1951) = 0 (SCHED_OTHER)
> sched_get_priority_max(SCHED_FIFO) = 99
> sched_setscheduler(1951, SCHED_OTHER, { 0 }) = 0
> rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> rt_sigaction(SIGWINCH, {0xb6f96550, [],
> SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL, [], 0}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> futex(0xb6fa62c4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> mmap2(NULL, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6bc3000
> mmap2(NULL, 1052672, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ac2000
> geteuid32() = 0
> open("/etc/passwd", O_RDONLY) = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, 0xbebf3acc) = -1 ENOTTY (Inappropriate ioctl for device)
> brk(0x38d000) = 0x38d000
> read(3, "root:x:0:0:root:/root:/bin/ash\nd"..., 4096) = 190
> close(3) = 0
> prctl(PR_GET_NAME, 0xb6bc3d04, 0, 0, 0) = 0
> gettid() = 1951
> write(1, "Create msgQ\n", 12Create msgQ
> ) = 12
> write(1, "start server\n", 13start server
> ) = 13
> sched_getaffinity(1951, 128, {1}) = 4
> sched_get_priority_min(SCHED_FIFO) = 1
> sched_get_priority_max(SCHED_FIFO) = 99
> mmap2(NULL, 65536, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6ab2000
> mprotect(0xb6ab2000, 4096, PROT_NONE) = 0
> clone(child_stack=0xb6ac10e8,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THRE
> AD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHIL
> D_CLEARTID, parent_tidptr=0xb6ac1588, tls=0xb6ac1950,
> child_tidptr=0xb6ac1588) = 1953
> sched_setaffinity(1953, 128, {2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}) = 0
> futex(0xb6ac1734, FUTEX_WAKE_PRIVATE, 1) = 1
> clock_gettime(CLOCK_REALTIME, {1462279873, 549992977}) = 0
> write(1, "server is up\n", 13server is up
> ) = 13
> write(1, "start sender\n", 13start sender
> ) = 13
> sched_get_priority_min(SCHED_FIFO) = 1
> sched_get_priority_max(SCHED_FIFO) = 99
> mmap2(NULL, 65536, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6aa2000
> mprotect(0xb6aa2000, 4096, PROT_NONE) = 0
> clone(child_stack=0xb6ab10e8,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THRE
> AD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHIL
> D_CLEARTID, parent_tidptr=0xb6ab1588, tls=0xb6ab1950,
> child_tidptr=0xb6ab1588) = 1954
> clock_gettime(CLOCK_REALTIME, {1462279873, 555642310}) = 0
> gettimeofday({1462279873, 556216}, NULL) = 0
> futex(0xbebf3b78, FUTEX_WAIT_PRIVATE, 0, {4, 443784000}) = 0
> futex(0xb6ab1588, FUTEX_WAIT, 1954, NULLsender is up
> send msg
> <unfinished ...>
> +++ killed by SIGSEGV +++
> Segmentation fault
>
>
> Thanks,
> Alex Plits.
>
[Alex Plits]
Sorry to nag -
Any input on this issue?
Thanks,
Alex Plits.
> > --
> > Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
2016-05-11 6:59 ` Alex Plits
@ 2016-05-23 9:14 ` Philippe Gerum
0 siblings, 0 replies; 13+ messages in thread
From: Philippe Gerum @ 2016-05-23 9:14 UTC (permalink / raw)
To: Alex Plits, Gilles Chanteperdrix; +Cc: xenomai
On 05/11/2016 08:59 AM, Alex Plits wrote:
>> sched_get_priority_min(SCHED_FIFO) = 1
>> sched_get_priority_max(SCHED_FIFO) = 99
>> mmap2(NULL, 65536, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xb6aa2000
>> mprotect(0xb6aa2000, 4096, PROT_NONE) = 0
>> clone(child_stack=0xb6ab10e8,
>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THRE
>> AD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHIL
>> D_CLEARTID, parent_tidptr=0xb6ab1588, tls=0xb6ab1950,
>> child_tidptr=0xb6ab1588) = 1954
>> clock_gettime(CLOCK_REALTIME, {1462279873, 555642310}) = 0
>> gettimeofday({1462279873, 556216}, NULL) = 0
>> futex(0xbebf3b78, FUTEX_WAIT_PRIVATE, 0, {4, 443784000}) = 0
>> futex(0xb6ab1588, FUTEX_WAIT, 1954, NULLsender is up
>> send msg
>> <unfinished ...>
>> +++ killed by SIGSEGV +++
>> Segmentation fault
>>
>>
>> Thanks,
>> Alex Plits.
>>
> [Alex Plits]
> Sorry to nag -
> Any input on this issue?
>
Nothing obvious here. Could you try strace -f, so that spawned threads
are straced a well?
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-05-23 9:14 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-04 13:42 [Xenomai] Mixing Posix RT APIs and vxWorks APIs Alex Plits
2016-04-05 7:02 ` Gilles Chanteperdrix
2016-04-07 5:56 ` Alex Plits
2016-04-07 17:56 ` Philippe Gerum
2016-04-25 10:03 ` Alex Plits
2016-04-25 10:38 ` Philippe Gerum
2016-04-25 10:41 ` Philippe Gerum
2016-04-25 11:42 ` Alex Plits
2016-04-26 8:10 ` Alex Plits
2016-05-02 19:17 ` Philippe Gerum
2016-05-03 13:06 ` Alex Plits
2016-05-11 6:59 ` Alex Plits
2016-05-23 9:14 ` 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.