rqt plugin: crash with 'std::bad_alloc'

asked 2019-04-19 02:41:18 -0500

THordijk gravatar image

updated 2019-04-19 08:48:31 -0500

I have a rqt plugin that i run as a standalone. I am using ROS kinetic on ubuntu 16.04. The rqt plugin was created using QT creator 4.8.1 based on QT 5.12.

When I run all my nodes seperately the rqt plugin has the tendency to terminate itself, giving a std::'bad alloc' as error message.

I thought this might be related to the amount of data passing through the program so i created a bag file, in an attempt to get an idea of the data flow. I am not sure if the bag file is representative of this, so please correct me if I am wrong. The file that was returned after 1 minute of logging has a size of 5.3gb, and my processor is idling at around 80 - 90% over all 16 threads with 3.4 ghz. Could the crashing of rqt be related to this?

The error message that is returned is as follows:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
edit retag flag offensive close merge delete

Comments

1

std::bad_alloc points to problems encountered while trying to allocate memory.

In normal (ie: correctly operating) programs, these do not happen often, so I would suggest to look for memory leaks, pointer arithmetic and/or creation/initialisation of containers (ie: std::vector or std::list) based on incoming data (fi: reserve()ing a std::vector based on an incoming integer, where the integer is too large).

The file that was returned after 1 minute of logging has a size of 5.3gb

that implies a rate of about 90 MB/sec, which is quite high, unless you have something like a high-res 2D or 3D camera or lidar-like sensor in your setup.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-19 03:28:49 -0500 )edit

I am using a Ensenso N35, which is, indeed, a 3d stereo camera that also publishes a generated point cloud at 1.3mp 1280*1024, the images are then passed to a neural net.

THordijk gravatar image THordijk  ( 2019-04-19 03:38:47 -0500 )edit

That would explain the data-rate.

For the std::bad_alloc I'd suggest running your plugin in gdb (or some other debugger, after having compiled it with debug symbols enabled) to pintpoint where the exception is being thrown.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-19 03:42:27 -0500 )edit

I've changed the title of your question to more accurately reflect the issue you encounter (instead of stating what you believe is the cause).

Could you also please copy-paste the full error message that is printed on the console (instead of paraphrasing it)?

gvdhoorn gravatar image gvdhoorn  ( 2019-04-19 04:03:55 -0500 )edit

I added it in the original question

THordijk gravatar image THordijk  ( 2019-04-19 08:48:42 -0500 )edit

You should consider decoupling the data processing from the user interface in rqt and debugging would be simplified: have a regular ros node that subscribes to the 3D data and publishes visualization and status messages out, and interacts with an rqt user interface through ros messages, perhaps uses dynamic reconfigure.

lucasw gravatar image lucasw  ( 2019-04-19 10:41:29 -0500 )edit

Okay I will give this a try.

THordijk gravatar image THordijk  ( 2019-04-23 00:36:52 -0500 )edit

@THordijk: have you run your rqt plugin in a gdb hosted session of rqt already? Changing things without knowing where the exception is thrown seems like guessing to me (which is not what you'd want to do).

gvdhoorn gravatar image gvdhoorn  ( 2019-04-23 01:01:59 -0500 )edit