From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1319401552.9644.YahooMailNeo@domain.hid> Date: Sun, 23 Oct 2011 13:25:52 -0700 (PDT) From: "haitaozhumail-disc@domain.hid" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1062241449-536289358-1319401552=:9644" Subject: [Xenomai-help] address spaces of real-time task and standard linux process Reply-To: "haitaozhumail-disc@domain.hid" List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "xenomai@xenomai.org" ---1062241449-536289358-1319401552=:9644 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,=0A=0ADo a standard Linux process and a real-time task (spawned by t= he standard Linux process with rt_task_create and rt_task_start ) share the= same address space? More specifically, I have a C++ program like this:=0A= =0AClass A{ =0A=0A//Definition of a class A=0A};=0A=0ART_TASK demo_task;=0A= =0A=A0void demo(void *arg){=0AA * pA =3D (A *)arg;=0A//Access the passed ob= ject via pA, e.g., pA->a...=0A=0A}=0A=0Aint main(){=0A...=0A=0A=A0 A *pA = =3D new A;=0A=A0 rt_task_create(&demo_task, "realtime_task", 0, 50, 0);=0A= =A0 rt_task_start(&demo_task, &demo, (void *)pA);=0A=0A=0A=A0 pause();=0A= =0A}=0A=0ACan the function demo() correctly access the object created in ma= in()? What if pA is a smart pointer defined in Boost library?=0A=0A=0AWith = Many Thanks,=0ATom=0A ---1062241449-536289358-1319401552=:9644 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,

Do a standard Linux process and a real-time task (spawned = by the standard Linux process with rt_task_create and rt_task_start ) share= the same address space? More specifically, I have a C++ program like this:=

Class A{

//Definition of a class A=

};

RT_TASK demo_task;

void= demo(void *arg){

A * pA =3D (A *)arg;

//Access the pas= sed object via pA, e.g., pA->a...

}

int main(){

...

A *pA =3D new A;

rt_task_create(&demo_task, "realtime_task", 0, 50, 0);
&nbs= p; rt_task_start(&demo_task, &demo, (void *)pA);

pause();

}

Can the function = demo() correctly access the object created in main()? What if pA is a smart= pointer defined in Boost library?

= With Many Thanks,

Tom

---1062241449-536289358-1319401552=:9644-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4EA5916E.2030708@domain.hid> Date: Mon, 24 Oct 2011 09:25:18 -0700 From: Thomas Lockhart MIME-Version: 1.0 References: <1319401552.9644.YahooMailNeo@domain.hid> In-Reply-To: <1319401552.9644.YahooMailNeo@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "haitaozhumail-disc@domain.hid" Cc: "xenomai@xenomai.org" On 10/23/2011 01:25 PM, haitaozhumail-disc@domain.hid wrote: > Hi All, > > Do a standard Linux process and a real-time task (spawned by the > standard Linux process with rt_task_create and rt_task_start ) share the > same address space? More specifically, I have a C++ program like this: ... > Can the function demo() correctly access the object created in main()? > What if pA is a smart pointer defined in Boost library? Yes, yes, and yes (though I didn't look at the actual code, the address space is shared). For things like smart pointers, just make sure that someone is keeping a reference to the object so the reference count does not go to zero. hth - Tom From mboxrd@z Thu Jan 1 00:00:00 1970 References: Message-ID: <1319490255.1417.YahooMailNeo@domain.hid> Date: Mon, 24 Oct 2011 14:04:15 -0700 (PDT) From: Tom Z MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1498488837-480329272-1319490255=:1417" Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process Reply-To: Tom Z List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Lockhart Cc: "\"xenomai@xenomai.org\"" --1498488837-480329272-1319490255=:1417 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for Thomas' answer.=0A=0AThe previous code I showed was truncated fo= r simplicity. The actual code is a little more complicated.=A0=0A=0AI am wr= iting a C++ program on Robotic Operating System (www.ROS.org) on Ubuntu 10.= 10 patched with Xenomai 2.5.6. This program processes video captured from a= USB camera. It has 3 major functions:=0A=0Aint main (int argc, char ** arg= v): Initializes the whole program, create a message pipe for communication = between the standard Linux process and a real-time (Xenomai) task.=0A=0Avoi= d imageCb (const sensor_msgs::ImageConstPtr& msg): A callback function runn= ing in the *standard Linux Process*. It is called whenever an image frame i= s available, and it sends a message to the real-time task mentioned above.= =0A=0Avoid rtImageProcessing (void * arg): This is the real-time (Xenomai) = task that is supposed to process images.=0A=0AThe above functions are as fo= llows: (For simplicity, I omitted some unimportant codes)=0A=0A1) int main = (int argc, char ** argv){=0A=A02)=A0=0A=A03) =A0 =A0 rt_print_auto_init(1);= =0A=A04) =A0 =A0 mlockall(MCL_CURRENT|MCL_FUTURE);=0A=A05) =A0 =A0 //Create= a message pipe for the real-time task=0A=A06) =A0 =A0 rt_pipe_create(&pipe= _desc, NULL, PIPE_MINOR, 0);=0A=A07) =A0 =A0 //Initialize the real-time tas= k=0A=A08) =A0 =A0 rt_task_create(&task_desc, "RealTimeImageProcessing", 409= 6, 99, T_FPU|T_CPU(0));=0A=A09) =A0 =A0 rt_task_start(&task_desc, &rtImageP= rocessing, NULL);=0A10)=A0=0A11) =A0 =A0 //Create a message pipe for the st= andard Linux process=0A12) =A0 =A0 char devname[32];=A0=0A13) =A0 =A0 sprin= tf(devname, "/dev/rtp%d", PIPE_MINOR);=A0=0A14) =A0 =A0 pipe_fd =3D open(de= vname, O_RDWR);=0A15)=A0=0A16)=A0=0A17) =A0 =A0 //Setup the callback functi= on=0A18) =A0 =A0 //....=0A19)=A0=0A20) =A0 =A0 pause(); //Waiting=0A21)=A0= =0A22) =A0 =A0 //Clean up the tasks & pipes=0A23) }=0A24)=A0=0A25)=A0=0A26)= void imageCb(const sensor_msgs::ImageConstPtr& msg){=0A27)=A0=0A28) =A0 = =A0 int len =3D sizeof(sensor_msgs::ImageConstPtr *);=0A29) =A0 =A0 int ptr= _as_int =3D (int)&msg;=0A30) =A0 =A0 //Write the address of msg to the pipe= , so rtImageProcessing() gets msg's address, and interprets this address as= a pointer to msg.=0A31) =A0 =A0 write(pipe_fd, (const void*)&ptr_as_int, l= en);=A0=0A32) }=0A33) //sensor_msgs::ImageConstPtr is a class defined in RO= S libraries, and it looks like this:=0A34) //typedef boost::shared_ptr< ::s= ensor_msgs::Image const> ImageConstPtr;=0A35) //where ::sensor_msgs::Image = is a class for an image in ROS. Not sure if it matters how ::sensor_msgs::I= mage is defined, so the definition is omitted for simplicity=0A36)=A0=0A37)= void rtImageProcessing (void * arg){=0A38) =A0 =A0 char read_buf[8];=0A39)= =A0 =A0 int ptr_as_int;=0A40) =A0 =A0 int len =3D sizeof(sensor_msgs::Imag= eConstPtr *);=0A41) =A0 =A0 sensor_msgs::ImageConstPtr * p_msg;=0A42)=A0=0A= 43) =A0 =A0 while (1) {=0A44) =A0 =A0 =A0 =A0 rt_pipe_read(&pipe_desc, (voi= d *)read_buf, len, TM_INFINITE);=0A45) =A0 =A0 =A0 =A0 ptr_as_int =3D *((in= t*)read_buf);=0A46) =A0 =A0 =A0 =A0 p_msg =3D (sensor_msgs::ImageConstPtr *= )ptr_as_int;=0A47) =A0 =A0 =A0 =A0=A0=0A48) =A0 =A0 =A0 =A0 cv_bridge::CvIm= agePtr cv_ptr;=0A49) =A0 =A0 =A0 =A0 cv_ptr =3D cv_bridge::toCvCopy(*p_msg,= enc::BGR8);=0A50) =A0 =A0 =A0 =A0 //... More image processing codes go her= e =A0=A0=0A51) =A0 }=0A52) }=0A=0A=0AIn=A0rtImageProcessing() I can use (*p= _msg) as a pointer to msg to access some basic info of msg, e.g., (*p_msg)-= >height. But the program has a segment fault when executing Line 49). I hav= e made sure that the codes after Line 49) can, if running in the standard L= inux process w/ msg as an argument (that is, do not use a real-time task fo= r image processing), run correctly, so it is not the poor design of image p= rocessing codes that cause this problem. I suspect that the problem comes f= rom the accessing of a smart pointer across different processes, but I am n= ot sure, and I am still struggling with this problem...=0A=0A=0AAny ideas o= r suggestions will be highly appreciated.=0ATomZ=0A=0A=0A=0AOn Mon, Oct 24,= 2011 at 11:25 AM, Thomas Lockhart wrote:=0A= =0A=A0 =A0 On 10/23/2011 01:25 PM, haitaozhumail-disc@domain.hid wrote:=0A= =0A=A0 =A0 =A0 =A0 Hi All,=0A=0A=A0 =A0 =A0 =A0 Do a standard Linux process= and a real-time task (spawned by the=0A=A0 =A0 =A0 =A0 standard Linux proc= ess with rt_task_create and rt_task_start ) share the=0A=A0 =A0 =A0 =A0 sam= e address space? More specifically, I have a C++ program like this:=A0=0A= =0A=A0 =A0 ...=0A=0A=A0 =A0 =A0 =A0 Can the function demo() correctly acces= s the object created in main()?=0A=A0 =A0 =A0 =A0 What if pA is a smart poi= nter defined in Boost library?=A0=0A=0A=A0 =A0 Yes, yes, and yes (though I = didn't look at the actual code, the address space is shared).=0A=0A=A0 =A0 = For things like smart pointers, just make sure that someone is keeping a re= ference to the object so the reference count does not go to zero.=0A=0A=A0 = =A0 hth=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Tom=A0 --1498488837-480329272-1319490255=:1417 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for Thomas' answer.

The previous code I showed was truncated fo= r simplicity. The actual code is a little more complicated.

I am writing a C++ program on Robotic Op= erating System=0A (www.ROS.org) on Ubuntu 10.10 patched with Xenomai 2.5.6.= This progr= am processes video captured from a USB camera. It has 3 major functions:

int main (int argc, char ** argv): Initializes the whole program, create a= message pipe for communication between the standard Linux process and a re= al-time (Xenomai) task.

void imageCb (const sensor_msgs::ImageConstPtr& msg): A callback f= unction running in the *standard Linux Process*. It is called whenever an i= mage frame is available, and it sends a message to the real-time task menti= oned above.

void rtImageProcessing (void * arg): This i= s the real-time (Xenomai) task that is supposed to process images.

The above functions are as follows: (For simplicity, I omitted som= e unimportant codes)

1) int main (int argc, char ** argv){

<= div id=3D"yiv617584859yui_3_2_0_15_131947690534840" class=3D"yui_3_2_0_14_1= 31947716813670">&n= bsp;2)

3) rt_print_auto_init(1)= ;

4) mlockall(MCL_CURRENT|MCL_FUTUR= E);

5) //Create a message pipe for th= e real-time task

6) rt_pipe_create(&a= mp;pipe_desc, NULL, PIPE_MINOR, 0);

7) //Initialize the real-time = task

8) rt_task_create(&task_desc= , "RealTimeImageProcessing", 4096, 99, T_FPU|T_CPU(0));

&= nbsp;9) rt_task_start(&task_desc, &rtImageProcessing,= NULL);

1= 0)

11) //Create a message pipe for th= e standard Linux process

12) char devname[3= 2];

13) sprintf(devname, "/dev/rtp%d"= , PIPE_MINOR);

14) pipe_fd =3D open(de= vname, O_RDWR);

15)

16)

1= 7) //Setup the callback function

18) &nb= sp; //....

19)

20) = pause(); //Waiting

21)

22) //Clean= up the tasks & pipes

23) }

24)&n= bsp;

25)&n= bsp;

26) void imageCb(const sensor_msgs::ImageConstPtr&am= p; msg){

27)

28) int len =3D sizeof(sensor_msgs::Imag= eConstPtr *);

29) int ptr_as_int =3D (int)&= amp;msg;

30) //Write the address of msg to = the pipe, so rtImageProcessing() gets msg's address, and interprets this ad= dress as a pointer to msg.

31) write(pipe_fd, (const void*)&ptr= _as_int, len);

32) }

33) //s= ensor_msgs::ImageConstPtr is a class defined in ROS libraries, and it looks= like this:

34) //typedef boost::shared_ptr< ::sensor_= msgs::Image const> ImageConstPtr;

35) //where ::sensor_msgs::Image is a cla= ss for an image in ROS. Not sure if it matters how ::sensor_msgs::Image is = defined, so the definition is omitted for simplicity

36)&= nbsp;

37) void rtImageProcessing (void * arg){

38) &= nbsp; char read_buf[8];

39) int ptr_= as_int;

40) int len =3D sizeof(sensor_msgs:= :ImageConstPtr *);

4= 1) sensor_msgs::ImageConstPtr * p_msg;

42)&= nbsp;

43) while (1) {

44)= rt_pipe_read(&pipe_desc, (void *)read_buf,= len, TM_INFINITE);

45) ptr_as_int= =3D *((int*)read_buf);

46) p= _msg =3D (sensor_msgs::ImageConstPtr *)ptr_as_int;

47) &n= bsp;

48) cv_bridge::CvImagePtr= cv_ptr;

49) cv_ptr =3D cv_br= idge::toCvCopy(*p_msg, enc::BGR8);

50) &nbs= p; //... More image processing codes go here

51) }

52) }

In rtImageProcessing() I can use (*p_msg) as a pointer= to msg to access some basic info of msg, e.g., (*p_msg)->height. But the program has a segment faul= t when executing Line 49). I have made sure that the codes after Line 49) c= an, if running in the standard Linux process w/ msg as an argument (that is= , do not use a real-time task for image processing), run correctly, so it i= s not the poor design of image processing codes that cause this problem. I = suspect that the problem comes from the accessing of a smart pointer across= different processes, but I am not sure, and I am still struggling with thi= s problem...

<= /span>

Any ideas or su= ggestions will be highly appreciated.

TomZ

On Mon, Oct 24, 2011 at 11= :25 AM, Thomas Lockhart <Thomas.Lockhart@domain.hid> wrote:<= /div>

On 10/23/2011 01:25 PM, haitaozhumail-disc@= yahoo.com wrote:

= ; Hi All,

Do a s= tandard Linux process and a real-time task (spawned by the

standard Linux process with= =0A rt_task_create and rt_task_start ) share the

= same address space? More specifically, I have a C++ program = like this:

...

= Can the function demo() correctly acces= s the object created in main()?

Wh= at if pA is a smart pointer defined in Boost library?

Yes, yes, and yes (though I didn't look at th= e actual code, the address space is shared).

&nb= sp; For things like smart pointers, just make sure that someone is k= eeping a reference to the object so=0A the reference count does not go to z= ero.

hth

&= nbsp; - Tom

--1498488837-480329272-1319490255=:1417-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4EA66DF8.3050601@domain.hid> Date: Tue, 25 Oct 2011 10:06:16 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1319490255.1417.YahooMailNeo@domain.hid> In-Reply-To: <1319490255.1417.YahooMailNeo@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Z Cc: "xenomai@xenomai.org" On 10/24/2011 11:04 PM, Tom Z wrote: > Any ideas or suggestions will be highly appreciated. TomZ Try gdb. If that fails, get the kernel to print the value of the registers when the fault happens, then disassemble and look at why the fault happens. -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4EA69486.4030106@domain.hid> Date: Tue, 25 Oct 2011 12:50:46 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1319490255.1417.YahooMailNeo@domain.hid> In-Reply-To: <1319490255.1417.YahooMailNeo@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Z Cc: "xenomai@xenomai.org" On 10/24/2011 11:04 PM, Tom Z wrote: > 8) rt_task_create(&task_desc, "RealTimeImageProcessing", 4096, 99, T_FPU|T_CPU(0)); 4096 bytes is a really small stack size, are you sure that the segmentation fault is simply not a stack overflow? -- Gilles. From mboxrd@z Thu Jan 1 00:00:00 1970 References: <1319490255.1417.YahooMailNeo@domain.hid> <4EA69486.4030106@domain.hid> Message-ID: <1319638430.4857.YahooMailNeo@domain.hid> Date: Wed, 26 Oct 2011 07:13:50 -0700 (PDT) From: Tom Z In-Reply-To: <4EA69486.4030106@domain.hid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1735753853-1879321393-1319638430=:4857" Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process Reply-To: Tom Z 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" --1735753853-1879321393-1319638430=:4857 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AThanks. I increased the stack size and the problem was gone. This pro= blem was hard to find for me, as when I step into the functions in gdb, the= locations where the problem occurs are different.=0A=0A=0ABTW, in your pre= vious reply you mentioned debugging techniques such as examining the regist= ers and disassembling, can you suggesting some readings that elaborate such= techniques. I have a few questions regarding such techniques, e.g., how do= I interpret the meaning of each register? By disassembling, do you mean lo= oking at the assembly codes?=0A=0A=0AThanks,=0ATom=0A=0A=0A=0A_____________= ___________________=0AFrom: Gilles Chanteperdrix =0ATo: Tom Z =0ACc: Thomas Lockhart ; "xenomai@xenomai.org" =0ASent: Tu= esday, 25 October 2011 5:50 AM=0ASubject: Re: [Xenomai-help] address spaces= of real-time task and standard linux process=0A=0AOn 10/24/2011 11:04 PM, = Tom Z wrote:=0A>=A0 8)=A0 =A0 rt_task_create(&task_desc, "RealTimeImagePro= cessing", 4096, 99, T_FPU|T_CPU(0));=0A=0A4096 bytes is a really small stac= k size, are you sure that the=0Asegmentation fault is simply not a stack ov= erflow?=0A=0A-- =0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0 = =A0 Gilles. --1735753853-1879321393-1319638430=:4857 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks. I increased the stack size and the problem was gone. Th= is problem was hard to find for me, as when I step into the functions in gd= b, the locations where the problem occurs are different.

BTW, in your previous reply you mentioned debugging techniques s= uch as examining the registers and disassembling, can you suggesting some r= eadings that elaborate such techniques. I have a few questions regarding su= ch techniques, e.g., how do I interpret the meaning of each register? By di= sassembling, do you mean looking at the assembly codes?

<= /div>

Thanks,

Tom

From: Gilles Chanteperdrix <gilles.chanteper= drix@domain.hid>
To: Tom Z <tomz30@domain.hid>
C= c: Thomas Lockhart <Thomas.Lockhart@domain.hid>; "xenoma= i-help@domain.hid" <xenomai@xenomai.org>
Sent: Tuesday, 25 October 2011 5:50 AM
Subject: Re: [Xenomai-help] address s= paces of real-time task and standard linux process

On 10/24/2= 011 11:04 PM, Tom Z wrote:
> 8) rt_task_create(&a= mp;task_desc, "RealTimeImageProcessing", 4096, 99, T_FPU|T_CPU(0));

= 4096 bytes is a really small stack size, are you sure that the
segmentat= ion fault is simply not a stack overflow?

--
= ; Gilles.

--1735753853-1879321393-1319638430=:4857-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4EA81F08.4040509@domain.hid> Date: Wed, 26 Oct 2011 16:54:00 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <1319490255.1417.YahooMailNeo@domain.hid> <4EA69486.4030106@domain.hid> <1319638430.4857.YahooMailNeo@domain.hid> In-Reply-To: <1319638430.4857.YahooMailNeo@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Z Cc: "xenomai@xenomai.org" On 10/26/2011 04:13 PM, Tom Z wrote: > > > Thanks. I increased the stack size and the problem was gone. This > problem was hard to find for me, as when I step into the functions in > gdb, the locations where the problem occurs are different. > > > BTW, in your previous reply you mentioned debugging techniques such > as examining the registers and disassembling, can you suggesting some > readings that elaborate such techniques. I have a few questions > regarding such techniques, e.g., how do I interpret the meaning of > each register? By disassembling, do you mean looking at the assembly > codes? The best I could find is this: http://www.urbanmyth.org/linux/oops/slides.html Which explains how to debug a kernel oops. The method transpose easily to user-space. In case of stack overflow, the stack pointer register should show an address not mapped, or mapped read-only. You can see a process mappings in /proc/pid/maps (if you want this file to exist in case of a segfault, install a signal for SIGSEGV which calls the pause() function). But if gdb does not modify the program behaviour, debugging with gdb is much easier. -- Gilles.