-
Hello,
I am now using Qt and a QPushButton is connected to a function that creates an sf::RenderWindow. It appears that the following line is stalled:
GS::window.create(sf::VideoMode(GS::resWidth, GS::resHeight), "Some Window :D");
I was expecting to see a new window pop up (monitored by SFML) when the QPushButton is clicked, but instead the program fizzles. Is there something I should know about using Qt and SFML together?
-
the program fizzles
I have no idea what this means :P
Do you have an event loop for your window?
-
the program fizzles
I have no idea what this means :P
Do you have an event loop for your window?
Oh, I only meant that if I print a foo right before, and a foo right after this line, I only get one foo. Yes there's a loop, but my program seems to take infinite time to get past this line, so I never reach the while loop.
-
Does the line work in a standalone program without Qt? Maybe there's something incompatible or wrong with your build environment.
-
Does the line work in a standalone program without Qt? Maybe there's something incompatible or wrong with your build environment.
Yes, I'm actually merging my SFML project with my Qt project, and the former project was working well before.
Well, even during QApplication::exec, it is possible to create non-Qt windows, right? I mean, nothing in the part of my project that is related to SFML, inherits from QWidget.
-
So I've actually tried the 1.6 tutorial. I wasn't aware that you couldn't launch an SFML Window out of nowhere when you're already using Qt.
QSFMLCanvas.hpp
#pragma once
#include <QTimer>
#include <QWidget>
#include <SFML/Graphics.hpp>
class QSFMLCanvas : public QWidget, public sf::RenderWindow
{
private:
QTimer myTimer;
bool myInitialized;
public:
explicit QSFMLCanvas(QWidget*, const QPoint&, const QSize&, unsigned int = 0);
QSFMLCanvas(void);
virtual ~QSFMLCanvas(void);
virtual void showEvent(QShowEvent*);
virtual QPaintEngine* paintEngine(void) const;
virtual void paintEvent(QPaintEvent*);
virtual void OnInit(void);
virtual void OnUpdate(void);
};
QSFMLCanvas.cpp (not using X11... I mean, if I were using this, I would know right?)
#include <iostream>
#include "QSFMLCanvas.hpp"
QSFMLCanvas::QSFMLCanvas(QWidget* Parent, const QPoint& Position, const QSize& Size, unsigned int FrameTime) :
QWidget(Parent),
myInitialized (false)
{
// Setup some states to allow direct rendering into the widget
setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_OpaquePaintEvent);
setAttribute(Qt::WA_NoSystemBackground);
// Set strong focus to enable keyboard events to be received
setFocusPolicy(Qt::StrongFocus);
// Setup the widget geometry
move(Position);
resize(Size);
// Setup the timer
myTimer.setInterval(FrameTime);
}
QSFMLCanvas::QSFMLCanvas(void)
{
}
QSFMLCanvas::~QSFMLCanvas(void)
{
}
void QSFMLCanvas::showEvent(QShowEvent*)
{
if (not myInitialized)
{
// Under X11, we need to flush the commands sent to the server to ensure that
// SFML will get an updated view of the windows
//XFlush(QX11Info::display());
// Create the SFML window with the widget handle
RenderWindow::create(static_cast<sf::WindowHandle>(winId()));
// Let the derived class do its specific stuff
OnInit();
// Setup the timer to trigger a refresh at specified framerate
connect(&myTimer, SIGNAL(timeout()), this, SLOT(repaint()));
myTimer.start();
myInitialized = true;
}
}
QPaintEngine* QSFMLCanvas::paintEngine(void) const
{
return 0;
}
void QSFMLCanvas::paintEvent(QPaintEvent*)
{
// Let the derived class do its specific stuff
OnUpdate();
// Display on screen
RenderWindow::display();
}
void QSFMLCanvas::OnInit(void)
{
}
void QSFMLCanvas::OnUpdate(void)
{
}
MyCanvas.hpp
#pragma once
#include <SFML/Graphics.hpp>
#include "QSFMLCanvas.hpp"
class MyCanvas : public QSFMLCanvas
{
private:
sf::Clock myClock;
sf::Texture myImage;
sf::Sprite mySprite;
public:
MyCanvas(QWidget*, const QPoint&, const QSize&);
MyCanvas(void);
~MyCanvas(void);
void OnInit(void);
void OnUpdate(void);
};
MyCanvas.cpp
#include <iostream>
#include <QDir>
#include <string>
#include "MyCanvas.hpp"
MyCanvas::MyCanvas(QWidget* Parent, const QPoint& Position, const QSize& Size) : QSFMLCanvas(Parent, Position, Size)
{
}
MyCanvas::MyCanvas(void)
{
}
MyCanvas::~MyCanvas(void)
{
}
void MyCanvas::OnInit(void)
{
// Load the image
std::cout << "onInit" << std::endl;
QString dir = QDir::currentPath();
std::string utf8_text = dir.toUtf8().constData();
std::cout << "HELLO: " << utf8_text << std::endl;
if (not myImage.loadFromFile(utf8_text + "/chef.png"))
std::cout << "Loading error"<< std::endl;
else
std::cout << "Image was loaded fine" << std::endl;
// Setup the sprite
mySprite.setTexture(myImage);
mySprite.setPosition(150, 150);
std::cout << "setting the texture of the sprite" << std::endl;
//mySprite.setCenter(mySprite.GetSize() / 2.f);
myClock.restart();
}
void MyCanvas::OnUpdate(void)
{
// Clear screen
RenderWindow::clear(sf::Color(0, 128, 0));
// Rotate the sprite
mySprite.rotate(myClock.getElapsedTime().asSeconds() * 100.f);
// Draw it
RenderWindow::draw(mySprite);
myClock.restart();
}
The QFrame and MyCanvas instances are defined as public static std::shared_ptr of some class:
class WindowFrame : public QObject
{
Q_OBJECT
// ...
public:
static std::shared_ptr<QFrame> SFMLFrame;
static std::shared_ptr<MyCanvas> SFMLWindow;
WindowFrame(void);
~WindowFrame(void);
// ...
};
Now, here's what my main function looks like:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
WindowFrame::SFMLFrame = std::make_shared<QFrame>();
WindowFrame::SFMLFrame->setWindowTitle("Qt SFML");
WindowFrame::SFMLFrame->resize(GS::resWidth, GS::resHeight);
WindowFrame::SFMLFrame->show();
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
WindowFrame::SFMLFrame->show();
// stuff irrelevant to SFML
return app.exec();
}
But I still have the same problem as before... The following line is stalled indefinitely, when I press a QPushButton that causes its execution:
WindowFrame::SFMLWindow->sf::RenderWindow::create(sf::VideoMode(GS::resWidth, GS::resHeight), "Some Window :D");
So, what am I doing wrong in all this? Is there nothing too redundant in doing:
WindowFrame::SFMLFrame->resize(GS::resWidth, GS::resHeight);
// ...
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
Thank you in advance.
-
I don't know if I understood the problem but it would not be easier to put the sfml window( the loop) in a separated thread and then call it.
-
You mean would right? Anyway I hear that using std::threads is very nasty for these things, so I'd rather avoid them for now.
I would really, really appreciate if someone could take the time to help me out here. I don't want to be a pain and bump this thread every day or so.
Addendum: I've just realized that the code in my main function has a mistake. It should be
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
WindowFrame::SFMLWindow->show();
not
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
WindowFrame::SFMLFrame->show();
Once I corrected that, my program stalls at
WindowFrame::SFMLWindow->show();
and doesn't even reach `app.exec()`
-
So I've actually tried the 1.6 tutorial. I wasn't aware that you couldn't launch an SFML Window out of nowhere when you're already using Qt.
Think about "who's managing the event loop"?...
-
Anyone know why calling QWidget::show() stalls the program? Also, how can I put my SFMLCanvas instance (SFMLWindow) in VideoMode without actually calling sf::RenderWindow::create(), which seems to stall the program as well ?
-
Help please. I can't seem to use show() without the entire program blocking. I've also injected
std::cout << "foo" << std::endl;
to see if any of the following functions
virtual void showEvent(QShowEvent*);
virtual QPaintEngine* paintEngine(void) const;
virtual void paintEvent(QPaintEvent*);
from QSFMLCanvas were called, it seems they aren't for whatever reason. The same trick shows that the following functions
void OnInit(void);
void OnUpdate(void);
from MyCanvas are never called either.
I'm starting to wonder if I posted my problem in the correct section. Window might have been more accurate. Or maybe General.
-
Well I understand that reading through the code isn't really interesting, so everybody's busy doing something else. But if I can't even get hints or methods on how to solve the problem myself, I really don't know where to go. I'm pretty sure the problem is basic though, as I've rarely had complicated problems in coding so far.
-
First, what do you want to do? The canvas is parented to the frame, but isn't inserted in it (with a layout for example). Or do you want two independant top-level windows?
Then you could simply use your debugger to find out where your program is blocked exactly (in which Qt call).
-
First, what do you want to do? The canvas is parented to the frame, but isn't inserted in it (with a layout for example). Or do you want two independant top-level windows?
Then you could simply use your debugger to find out where your program is blocked exactly (in which Qt call).
Thanks for your reply.
I don't understand, is there any need for Layouts? Either it's an oversight, or the tutorial I used didn't use any. I just gave the pointer of the Frame as the first parameter of the MyCanvas constructor:
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
I've never managed to use the debugger under Ubuntu, so I'd rather try out any other ways to solve this issue first :S
-
Before trying to integrate SFML into a Qt GUI, did you first learn Qt alone? Have you already successfully created a GUI without SFML?
-
Before trying to integrate SFML into a Qt GUI, did you first learn Qt alone? Have you already successfully created a GUI without SFML?
Absolutely, I actually had a Qt project and an SFML project, now I'm simply merging them and trying to integrate the SFML project into the Qt one. Compilation is no longer a problem, execution is.
-
So... if WindowFrame::SFMLWindow is not a SFML window, but instead, let's say, a QFrame, your application works flawlessly -- or at least doesn't block at startup?
-
My application doesn't block at startup if I give up using the method show.
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
WindowFrame::SFMLFrame = std::make_shared<QFrame>();
WindowFrame::SFMLFrame->setWindowTitle("Qt SFML");
WindowFrame::SFMLFrame->resize(GS::resWidth, GS::resHeight);
WindowFrame::SFMLFrame->show();
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
WindowFrame::SFMLWindow->show(); // blocks here
return app.exec();
}
The following code doesn't block at all:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
WindowFrame::SFMLFrame = std::make_shared<QFrame>();
WindowFrame::SFMLFrame->setWindowTitle("Qt SFML");
WindowFrame::SFMLFrame->resize(GS::resWidth, GS::resHeight);
WindowFrame::SFMLFrame->show();
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
//WindowFrame::SFMLWindow->show();
return app.exec();
}
(... but the window is kept blank indefinitely.)
The following code doesn't block at all as well, but no window shows up:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
WindowFrame::SFMLFrame = std::make_shared<QFrame>();
WindowFrame::SFMLFrame->setWindowTitle("Qt SFML");
WindowFrame::SFMLFrame->resize(GS::resWidth, GS::resHeight);
//WindowFrame::SFMLFrame->show();
WindowFrame::SFMLWindow = std::make_shared<MyCanvas>(WindowFrame::SFMLFrame.get(), QPoint(0, 0), QSize(GS::resWidth, GS::resHeight));
WindowFrame::SFMLWindow->show();
return app.exec();
}
Now, in either of these last two codes, if I later try to show the other widget (that is, WindowFrame::SFMLFrame for the third code, and WindowFrame::SFMLWindow for the second code) by pressing a QPushButton that is connected to a function that calls the show method, the program blocks just like it does in the first code.
-
My application doesn't block at startup if I give up using the method show.
I already know that, this is not what I asked.
-
My application doesn't block at startup if I give up using the method show.
I already know that, this is not what I asked.
In this case there is no blocking. I see another blank window when I execute the program.
-
And have you used the debugger to find out where the execution is blocked?
-
I'm not sure if I did the right thing, but I step 1000'ed until the program blocked, then interrupted it and where'd:
(gdb) where
#0 0x00007ffff3e5f089 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff3e47777 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff3e7e525 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff3e803f6 in _XimProtoOpenIM () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff3e847e8 in _XimOpenIM () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff776f851 in sf::priv::WindowImplX11::WindowImplX11(unsigned long) () from /usr/local/lib/libsfml-window.so.2.3
#6 0x00007ffff7765211 in sf::priv::WindowImpl::create(unsigned long) () from /usr/local/lib/libsfml-window.so.2.3
#7 0x00007ffff7764e5e in sf::Window::create(unsigned long, sf::ContextSettings const&) () from /usr/local/lib/libsfml-window.so.2.3
#8 0x00000000004d525c in QSFMLCanvas::showEvent (this=0x160e2b0) at QSFMLCanvas.cpp:39
#9 0x00007ffff67cd2a7 in QWidget::event (this=0x160e2b0, event=0x7fffffffdc10) at kernel/qwidget.cpp:8161
#10 0x00007ffff6791c8c in QApplicationPrivate::notify_helper (this=this@entry=0x1192ba0, receiver=receiver@entry=0x160e2b0, e=e@entry=0x7fffffffdc10) at kernel/qapplication.cpp:3486
#11 0x00007ffff6796e56 in QApplication::notify (this=0x7fffffffdd20, receiver=0x160e2b0, e=0x7fffffffdc10) at kernel/qapplication.cpp:3236
#12 0x00007ffff5bcbc2d in QCoreApplication::notifyInternal (this=0x7fffffffdd20, receiver=receiver@entry=0x160e2b0, event=event@entry=0x7fffffffdc10) at kernel/qcoreapplication.cpp:881
#13 0x00007ffff67ca57e in sendEvent (event=0x7fffffffdc10, receiver=0x160e2b0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232
#14 QWidgetPrivate::show_helper (this=this@entry=0x160e660) at kernel/qwidget.cpp:7164
#15 0x00007ffff67cc67a in QWidget::setVisible (this=0x160e2b0, visible=<optimized out>) at kernel/qwidget.cpp:7376
#16 0x000000000058cc7e in main (argc=1, argv=0x7fffffffdf18) at Menu.cpp:39
-
Ah... a X11 problem at window creation. I guess only binary1248 can help then. Any chance to try the same code on Windows or OS X?
-
What Linux distribution are you using? And what version of it? Reading around the internet, it looks like others had similar problems in the past. XCB and Xlib still contain bugs, and that is not even taking into account all of the buggy window managers out there. If you haven't already, make sure your system and all of your installed packages are up to date. This bug might have already been fixed by now.
-
Oh, well as I mentioned in post 6, I commented the XFlush thing because I thought I didn't need it (and also because I couldn't manage to find the right libraries and compile it). That might be the root of my problem then. I'm using Ubuntu 14.04 LTS.
The headers of QSFMLCanvas.cpp are now:
#include "QSFMLCanvas.hpp"
#include <QX11Info>
#include <X11/Xlib.h>
#include <iostream>
I uncommented the XFlush line and everything compiles just fine. When I execute the program though, I have the same problems. I'm going to check if the packages are up to date like binary said.
I updated everything and still have the problem :(
My current QSFMLCanvas.cpp file:
#include "QSFMLCanvas.hpp"
#include <QX11Info>
#include <X11/Xlib.h>
#include <iostream>
QSFMLCanvas::QSFMLCanvas(QWidget* Parent, const QPoint& Position, const QSize& Size, unsigned int FrameTime) :
QWidget(Parent),
myInitialized(false)
{
// Setup some states to allow direct rendering into the widget
setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_OpaquePaintEvent);
setAttribute(Qt::WA_NoSystemBackground);
// Set strong focus to enable keyboard events to be received
setFocusPolicy(Qt::StrongFocus);
// Setup the widget geometry
move(Position);
resize(Size);
// Setup the timer
myTimer.setInterval(FrameTime);
}
QSFMLCanvas::QSFMLCanvas(void)
{
}
QSFMLCanvas::~QSFMLCanvas(void)
{
}
void QSFMLCanvas::showEvent(QShowEvent*)
{
if (not myInitialized)
{
// Under X11, we need to flush the commands sent to the server to ensure that
// SFML will get an updated view of the windows
XFlush(QX11Info::display());
// Create the SFML window with the widget handle
RenderWindow::create(static_cast<sf::WindowHandle>(winId()));
// Let the derived class do its specific stuff
OnInit();
// Setup the timer to trigger a refresh at specified framerate
connect(&myTimer, SIGNAL(timeout()), this, SLOT(repaint()));
myTimer.start();
myInitialized = true;
}
std::cout << "show event" << std::endl;
}
QPaintEngine* QSFMLCanvas::paintEngine(void) const
{
std::cout << "paint engine" << std::endl;
return 0;
}
void QSFMLCanvas::paintEvent(QPaintEvent*)
{
// Let the derived class do its specific stuff
OnUpdate();
// Display on screen
RenderWindow::display();
std::cout << "paint event" << std::endl;
}
void QSFMLCanvas::OnInit(void)
{
}
void QSFMLCanvas::OnUpdate(void)
{
}
The std::cout lines are never reached.
-
So, what should I do? Is there some specific package that I should have installed? Program also seems to block at _XSend():
#0 0x00007ffff7ae0dab in _XSend () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff7ae1089 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff7ac9777 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff7b00525 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff7b023f6 in _XimProtoOpenIM () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff7b067e8 in _XimOpenIM () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff743a851 in sf::priv::WindowImplX11::WindowImplX11(unsigned long) () from /usr/local/lib/libsfml-window.so.2.3
#7 0x00007ffff7430211 in sf::priv::WindowImpl::create(unsigned long) () from /usr/local/lib/libsfml-window.so.2.3
#8 0x00007ffff742fe5e in sf::Window::create(unsigned long, sf::ContextSettings const&) () from /usr/local/lib/libsfml-window.so.2.3
#9 0x00000000004d5329 in QSFMLCanvas::showEvent (this=0x160df80) at QSFMLCanvas.cpp:39
#10 0x00007ffff62942a7 in QWidget::event (this=0x160df80, event=0x7fffffffdc10) at kernel/qwidget.cpp:8161
#11 0x00007ffff6258c8c in QApplicationPrivate::notify_helper (this=this@entry=0x1192ba0, receiver=receiver@entry=0x160df80, e=e@entry=0x7fffffffdc10) at kernel/qapplication.cpp:3486
#12 0x00007ffff625de56 in QApplication::notify (this=0x7fffffffdd20, receiver=0x160df80, e=0x7fffffffdc10) at kernel/qapplication.cpp:3236
#13 0x00007ffff5692c2d in QCoreApplication::notifyInternal (this=0x7fffffffdd20, receiver=receiver@entry=0x160df80, event=event@entry=0x7fffffffdc10) at kernel/qcoreapplication.cpp:881
#14 0x00007ffff629157e in sendEvent (event=0x7fffffffdc10, receiver=0x160df80) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232
#15 QWidgetPrivate::show_helper (this=this@entry=0x160e330) at kernel/qwidget.cpp:7164
#16 0x00007ffff629367a in QWidget::setVisible (this=0x160df80, visible=<optimized out>) at kernel/qwidget.cpp:7376
#17 0x000000000058cd8c in main (argc=1, argv=0x7fffffffdf18) at Menu.cpp:39
-
The fact that this stack is 1 layer deeper makes me think that your application isn't really blocking in the stricter sense. If you break and continue running the application in your debugger multiple times, you might notice that something is happening in the background. The thing is that you don't see anything happen window-wise and thus you think the program must have hung somewhere.
SFML makes a call to XOpenIM in its window initialization code. If XOpenIM doesn't return because it is waiting for some other X event to arrive that never does, SFML will not be able to proceed since it doesn't have any influence over that. The fact is that this isn't supposed to happen, even in this scenario where you are using Qt and SFML side by side. Something "deeper down" that SFML doesn't have control over is misbehaving and I can't think of any workarounds.
Like I said, I read on the internet that other people have had similar issues in the past that were attributed to bugs in Xlib and XCB. Some of those bugs have been fixed by now, however I don't know if those fixes have propagated into Ubuntu 14.04 LTS. You can try updating all your installed packages using your package manager. If they haven't, then you are out of luck. If you have another system at your disposal, you can test your code on an Ubuntu 14.10 or 15.04 system and see if the problem persists.
-
Thank you for taking the time to break it down for me.
It does seem that I'm out of luck. I have other computers (all Windows) at my disposal, but I would have to install everything (Qt, SFML, something that compiles C++ could be useful as well). Not to mention, I'm now used to Ubuntu and have gotten quite unfamiliar with Windows and C++ compilation in general. I think I'm going to use a laptop I have, install Ubuntu 15.04 on it and see how this plays out.
As a matter of fact, I have already encountered several un-explainable Qt problems with the computer I'm currently using. Qt::AlignJustify doesn't work for no reason, for instance. I've never had any problems with SFML though, as a result I've always assumed that most of my problems were due to Qt, not due to my computer. It's strange in a way because I chose 14.04 LTS, over the regular version of Ubuntu, to avoid silly problems, precisely.
I suppose I'll update my status in the near future :)
-
Well I've tested my program on Ubuntu 15.04 and I have different problems. I -think- that the above problems are solved, but I can't be sure because I have another issue to take care of before I can finally see for myself.
It seems that sf::Texts cause problems when I try to sf::RenderWindow::draw them. Some traces:
./Menu(_Z7Handleri+0x56)[0x54916c]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)[0x7fe704668d10]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xa4d2a)[0x7fe70437ad2a]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNSt8_Rb_treeIjSt4pairIKjN2sf4Font4PageEESt10_Select1stIS5_ESt4lessIjESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS1_+0x41)[0x7fe7064caea1]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Font8getGlyphEjjb+0x2b5)[0x7fe7064ca0b5]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Text20ensureGeometryUpdateEv+0x171)[0x7fe7064f4ca1]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Text4drawERNS_12RenderTargetENS_12RenderStatesE+0x1b)[0x7fe7064f5c5b]
/usr/local/lib/libsfml-graphics.so.2.3(_ZN2sf12RenderTarget4drawERKNS_8DrawableERKNS_12RenderStatesE+0x39)[0x7fe7064ea8e9]
Even if I comment some segfaulting lines, sf::Text::getLocalBounds also seems to be a problem sometimes:
./Menu(_Z7Handleri+0x56)[0x54a3a0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10)[0x7fa60931fd10]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Font14setCurrentSizeEj+0x13)[0x7fa60b17e383]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Font20getUnderlinePositionEj+0x16)[0x7fa60b17e656]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Text20ensureGeometryUpdateEv+0x134)[0x7fa60b1abc64]
/usr/local/lib/libsfml-graphics.so.2.3(_ZNK2sf4Text14getLocalBoundsEv+0xd)[0x7fa60b1acbad]
Again, this is some code that works perfectly on its own, if it is completely separated from Qt. I checked that separately on Ubuntu 15.04 too. Any ideas? :)
Thank you for your help so far!
-
Tip: if you run those stacktraces through 'c++filt' they should become a lot more readable since the tool will undo (demangle) the symbol name mangling the compiler did.
-
What do you mean? I'm basically launching this function:
void Handler(int sig)
{
std::cout << "Aborting..." << std::endl;
void *array[10];
size_t size;
// get void*'s for all entries on the stack
size = backtrace(array, 10);
// print out all the frames to stderr
fprintf(stderr, "Error: signal %d:\n", sig);
backtrace_symbols_fd(array, size, STDERR_FILENO);
exit(1);
}