0
$\begingroup$

Rosanswers logo

Hi everyone,

I have written a c++ node, which provides 2 different services which can be called one after another by a GUI. However the first service call works just fine. When I call the second service on of the two following error messages occur:

It is either:

Exception thrown while processing service call: basic_string::_M_create

or

Exception thrown while processing service call: std::bad_alloc

The callback function is quite simple and shall just execute on function using pointers and then return an int with the value of 1 as a response. The code looks like this:

bool callback(mybot::mysrv::Request &req, mybot::mysrv::Response &res){

     ros::AsyncSpinner spinner(10);
     spinner.start();   

     ROS_INFO("callback recieved");
     move_point->execute(*current_plan);
     res.status_res = 1;

     spinner.stop();
     return true;
}

The srv file contains:

int8 status_req
---
int8 status_res

EDIT:

If I delete the line move_point->execute(*current_plan); then the call works and just prints the ROS_INFO.

Seems to be a problem using the pointers then. However in the callback of the first service I use the line

move_point->execute(*current_plan);

and it works there, but not in the second function.


Originally posted by Felix_N on ROS Answers with karma: 115 on 2017-06-26

Post score: 1


Original comments

Comment by gvdhoorn on 2017-06-26:
Can you explain why you start an AsyncSpinner in your callback? This suggests that you either expect or have encountered unexpected or undesired behaviour with your callbacks or other events, but using AsyncSpinner like that is really not a good idea.

Comment by Felix_N on 2017-06-26:
I took the AsyncSpinner from a tutorial. Why is it bad? The error was somewhere else though.

Comment by gvdhoorn on 2017-06-26:
In almost 99% of the cases, callbacks should not start, stop, pause, create or destroy publishers, subscribers, nodehandles, timers, callback queues, spinners, etc, etc. All those things either:

  1. need time to initialise
  2. influence control and data flow

Instances of those things are ..

Comment by gvdhoorn on 2017-06-26:
.. necessary for your ROS node to function, but callbacks are not the place to deal with them, as it will either not work (because callbacks don't (or shouldn't) run long enough to allow proper initialisation (in the case of things like NodeHandles, pubs, subs) or it will cause your control ..

Comment by gvdhoorn on 2017-06-26:
.. flow to be strangely affected (seemingly missing messages, callbacks executed in strange order, etc).

An AsyncSpinner is not necessarily bad, but given the above, it should be created in the initialisation phase of your node.

Whenever you feel you need something like that inside a callback ..

Comment by gvdhoorn on 2017-06-26:
.. it is typically an indication of a conceptual issue that you're not handling correctly.

Can you explain why you instantiate that spinner in the callback?

Comment by Felix_N on 2017-06-26:
Thanks for the explanation. I wasn't really sure what it does. However I am working with moveit in my nodes. I just commented all the spinners outside the main loop. Now my functions can still be used as before but only once. Without the spinner, even such small callbacks ....

Comment by Felix_N on 2017-06-26:
... get stuck after execution, waiting for some return statements I guess. The function is only properly finished, if I wrap the whole thing into an additional spinner like I did in the example above. By the way: Without the spinners the calls were faster (but got stuck at the end like I mentioned)

Comment by gvdhoorn on 2017-06-26:
Without seeing the rest of your code I can only give you some general advice, but if your control flow requires it, you could just create an AsyncSpinner in your main and start it there. No need to stop it at the end, it'll be RAII-ed automatically. See if that helps.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Fixed it:

My pointer points to an object which was created in the first service call. Against my expectation declaring a pointer to that object does not prevent the object from destruction at the end of the function.

With the object being destroyed the pointer apparently points to some empty memory space and cannot access the methods anymore.

Instanciating object and pointer adress in the main loop solved the issue.


Originally posted by Felix_N with karma: 115 on 2017-06-26

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.