Revision history [back]

There are a couple of different things going on here.

First, the function signature of your node B is indeed a smart pointer; note, however, that ROS messages have value semantics, meaning that the image is copied (over the network); this means that your node B has a copy of the image in its address space.

By specifying B's callback to take an ImageConstPtr, you've specified that the ROS machinery should (a) get the message over the wire (b) save it as a smart pointer, and (c) pass a copy of that smart pointer to your callback. (Recall that smart pointers do reference counting.)

I can't speak to how Xenomai works; in general, a "process" is something with its own address space, not something that shares addresses; Xenomai may use that term a bit differently, or get around it using memory-mapped files or some other trick. I'll assume that B and R do, in fact, share an address space.

Are you, in fact, passing &msg to R? If so, that's likely your problem. Taking &msg generates a raw pointer to a smart pointer; then, when B's callback finishes, it destroys msg, and the ROS worker threads destroy their copy (because the callback is done), and now &msg points to a destroyed value, and you risk a segfault.

The easy fix is to have your callback take an ImagePtr, not an ImageConstPtr, and then to pass the smart pointer to R, not a raw pointer; that way, everybody gets a reference, and when B's callback and ROS' copies are destroyed, R still has a valid reference, with count 1.