[Xenomai-help] address spaces of real-time task and standard linux process

[Xenomai-help] address spaces of real-time task and standard linux process

[haitaozhumail-disc]

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

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 = (A *)arg;
//Access the passed object via pA, e.g., pA->a...

}

int main(){
...

  A *pA = new A;
  rt_task_create(&demo_task, "realtime_task", 0, 50, 0);
  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

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

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Thomas Lockhart]

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

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Tom Z]

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

Thanks for Thomas' answer.

The previous code I showed was truncated for simplicity. The actual code is a little more complicated. 

I am writing 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:

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

void imageCb (const sensor_msgs::ImageConstPtr& msg): A callback function running in the *standard Linux Process*. It is called whenever an image frame is available, and it sends a message to the real-time task mentioned above.

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

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

1) int main (int argc, char ** argv){
 2) 
 3)     rt_print_auto_init(1);
 4)     mlockall(MCL_CURRENT|MCL_FUTURE);
 5)     //Create a message pipe for the real-time task
 6)     rt_pipe_create(&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));
 9)     rt_task_start(&task_desc, &rtImageProcessing, NULL);
10) 
11)     //Create a message pipe for the standard Linux process
12)     char devname[32]; 
13)     sprintf(devname, "/dev/rtp%d", PIPE_MINOR); 
14)     pipe_fd = open(devname, O_RDWR);
15) 
16) 
17)     //Setup the callback function
18)     //....
19) 
20)     pause(); //Waiting
21) 
22)     //Clean up the tasks & pipes
23) }
24) 
25) 
26) void imageCb(const sensor_msgs::ImageConstPtr& msg){
27) 
28)     int len = sizeof(sensor_msgs::ImageConstPtr *);
29)     int ptr_as_int = (int)&msg;
30)     //Write the address of msg to the pipe, so rtImageProcessing() gets msg's address, and interprets this address as a pointer to msg.
31)     write(pipe_fd, (const void*)&ptr_as_int, len); 
32) }
33) //sensor_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 class for an image in ROS. Not sure if it matters how ::sensor_msgs::Image is defined, so the definition is omitted for simplicity
36) 
37) void rtImageProcessing (void * arg){
38)     char read_buf[8];
39)     int ptr_as_int;
40)     int len = sizeof(sensor_msgs::ImageConstPtr *);
41)     sensor_msgs::ImageConstPtr * p_msg;
42) 
43)     while (1) {
44)         rt_pipe_read(&pipe_desc, (void *)read_buf, len, TM_INFINITE);
45)         ptr_as_int = *((int*)read_buf);
46)         p_msg = (sensor_msgs::ImageConstPtr *)ptr_as_int;
47)         
48)         cv_bridge::CvImagePtr cv_ptr;
49)         cv_ptr = cv_bridge::toCvCopy(*p_msg, enc::BGR8);
50)         //... 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 fault when executing Line 49). I have made sure that the codes after Line 49) can, 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 is 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 this problem...


Any ideas or suggestions will be highly appreciated.
TomZ



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

    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 

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

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Tom Z]

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



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?


Thanks,
Tom



________________________________
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.orgmai.org>
To: Tom Z <tomz30@domain.hid>
Cc: Thomas Lockhart <Thomas.Lockhart@domain.hid>; "xenomai@xenomai.org" <xenomai@xenomai.org>
Sent: Tuesday, 25 October 2011 5:50 AM
Subject: Re: [Xenomai-help] address spaces of real-time task and standard linux process

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.

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

Re: [Xenomai-help] address spaces of real-time task and standard linux process

[Gilles Chanteperdrix]

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.