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 theSEGFAULT
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: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 nodeIt'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