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

[Tom Z <tomz30@domain.hid>]

[-- 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 --]