Robotics StackExchange | Archived questions

Segmentation fault (core dumped) depending on callback queue size?

I have a C++ Qt GUI to remote control a ROS kinetic robot. The mainwindow constructor starts a QThread in which a ros::MultiThreadedSpinner is started and subscribes to four different sensor_msgs/Image topics with four different image_transport::Subscriber and to one sensor_msgs/Imu with another Subscriber:

imageSubLeft = itLeft.subscribe("/camera_3/image_raw", 1000, &MainWindow::camCallbackLeft, this);
imageSubRight = itRight.subscribe("/camera_2/image_raw", 1000, &MainWindow::camCallbackRight, this);
imageSubRear = itRear.subscribe("/camera_1/image_raw", 1000, &MainWindow::camCallbackRear, this);
imageSubArm = itArm.subscribe("/camera_5/image_raw", 1000, &MainWindow::camCallbackArm, this);
imuSub = nh.subscribe("imu_data", 1, &MainWindow::imuCallback, this);

Further processing of the data is done in the callback functions, example for the cameras:

void MainWindow::camCallbackLeft(const sensor_msgs::Image::ConstPtr &msg)
{
    try
    {
        cvImgPtrLeft = cv_bridge::toCvCopy(msg, sensor_msgs::image_encodings::BGR8);
    }
    catch(cv_bridge::Exception &e)
    {
        ROS_ERROR("cv_bridge exception: %s", e.what());
        return;
    }
    camFrameLeft = cvImgPtrLeft->image;
    cvtColor(camFrameLeft, camFrameLeft, CV_BGR2RGB);
    camImgLeft = QImage((const unsigned char*)(camFrameLeft.data), camFrameLeft.cols, camFrameLeft.rows, QImage::Format_RGB888);
    labelLeft->setPixmap(QPixmap::fromImage(camImgLeft));
    labelLeft->resize(labelLeft->pixmap()->size());
}

For the IMU:

void MainWindow::imuCallback(const sensor_msgs::Imu::ConstPtr &msg)
{
    yVector[0] = msg->linear_acceleration.x;
    yVector[1] = msg->linear_acceleration.y;
    yVector[2] = msg->linear_acceleration.z;

    ahrsPlot->graph(0)->setData(xVector, yVector);

    ahrsPlot->replot();

}

With the IMU implemented the GUI quits and I get a segmentation fault (core dumped) message shortly after the program start (~ 60-90 seconds). When I initially had the callback queue size of the imuCallback at 1000 I thought it to be quicker than with the queue size at 100000. I just tried it with queue size 1 though and it does not seem to make a difference. When not subscribing to imu_data I have the same issues only it takes roughly 3 to 4 minutes.

Does someone have an idea what might cause this issue? When I saw people having a segmentation fault (core dumped) problem it seemed to be right after the program start with the reason being a not initialized pointer.

Please let me know if you need further information about the code and whatnot.

Edit: As suggested I ran the gdb. Since I can't seem to use ctrl+shift+c in Qt Creator I ran it again in a ordinary terminal with a slightly different output:

Thread 15 "RosThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa2ffd700 (LWP 15269)]
0x00007ffff2754e40 in QTransform::type() const ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5

Anyways here is the backtrace:

#0  0x00007ffff2754e40 in QTransform::type() const ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1  0x00007ffff26e2f65 in QRasterPaintEngine::drawImage(QPointF const&, QImage const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#2  0x00007ffff26e6f16 in QRasterPaintEngine::drawPixmap(QPointF const&, QPixmap const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#3  0x00007ffff2700f7b in QPainter::drawPixmap(QPointF const&, QPixmap const&)
    () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#4  0x0000000000549a14 in QPainter::drawPixmap (this=0x7fffa2ffb5a0, x=0, y=0, 
    pm=...) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qpainter.h:778
#5  0x00000000004ce92e in QCPPaintBufferPixmap::draw (this=0xdf54b0, 
    painter=0x7fffa2ffb5a0)
    at /home/user/catkin_ws_qtc/src/gui/src/qcustomplot.cpp:678
#6  0x00000000004fbee2 in QCustomPlot::paintEvent (this=0xdeaa40, 
    event=0x7fffa2ffb890)
    at /home/user/catkin_ws_qtc/src/gui/src/qcustomplot.cpp:14756
#7  0x00007ffff2aa4fc8 in QWidget::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007ffff2a6205c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x00007ffff2a67516 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x00007ffff216f38b in QCoreApplication::notifyInternal(QObject*, QEvent*)

Asked by Agricola on 2019-01-29 12:17:19 UTC

Comments

What does gdb tell you? Where is the SEGFAULT located?

Asked by gvdhoorn on 2019-01-29 12:24:21 UTC

I'm still kind of new to ROS and programming in general, so this is also the first time I get in contact with gdb. I don't get past the run command; it exits with code 126.

Asked by Agricola on 2019-01-31 03:28:19 UTC

You can run a node in gdb using something like:

gdb -ex run --args $CATKIN_WS/devel/lib/$pkg_name/$node_name

Where:

  • $CATKIN_WS is the path to your Catkin workspace
  • $pkg_name is the name of your pkg
  • $node_name is the name of your node

It's just a path, so use tab completion.

Asked by gvdhoorn on 2019-01-31 03:57:04 UTC

I got many new Thread and Thread exited messages and in the end Thread 1 "gui_node" received signal SIGSEGV, Segmentation fault. 0x00007ffff26dafa0 in QRasterPainEngine::compositionModeChanged() () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 Not really sure what to do with that.

Asked by Agricola on 2019-01-31 04:38:12 UTC

Type bt at the prompt and press enter.

Then copy-paste the full backtrace into your original question (use the edit button/link below it).

Asked by gvdhoorn on 2019-01-31 04:40:35 UTC

Had to rerun the gdb but the backtrace is now edited into the op.

Asked by Agricola on 2019-01-31 05:14:21 UTC

Answers