Okey, I recently found some time to look into this. The problem does NOT occur on SFML 2.3.2, not at all. I recompiled it and with the exact same Qt version it's ok. Also, it isn't a problem with my library only, any other way to get SFML render to Qt doesn't seem to work. Here's an other topic describing this problem:
http://en.sfml-dev.org/forums/index.php?topic=21070.0As drawing to native widget is an SFML feature (is it?), should I mark it as an issue on github?
//edit:
Here's backtrace:
//edit2:
Recompiled SFML 2.4.0 in debug mode; more precise backtrace.
#0 0x00007ffff5d57780 in recvmsg () at /usr/lib/libc.so.6
#1 0x00007ffff451aba7 in () at /usr/lib/libxcb.so.1
#2 0x00007ffff451b4d8 in () at /usr/lib/libxcb.so.1
#3 0x00007ffff52d4b89 in () at /usr/lib/libX11.so.6
#4 0x00007ffff52d4cfb in () at /usr/lib/libX11.so.6
#5 0x00007ffff52d4fed in _XEventsQueued () at /usr/lib/libX11.so.6
#6 0x00007ffff52b1bfb in XCheckIfEvent () at /usr/lib/libX11.so.6
#7 0x00007ffff79323d7 in sf::priv::WindowImplX11::processEvents() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:603
#8 0x00007ffff79337b2 in sf::priv::WindowImplX11::setVisible(bool) (this=0xadc020, visible=true) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:928
#9 0x00007ffff79359b4 in sf::priv::WindowImplX11::initialize() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:1607
#10 0x00007ffff7931905 in sf::priv::WindowImplX11::WindowImplX11(unsigned long) (this=0xadc020, handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:413
#11 0x00007ffff792a52f in sf::priv::WindowImpl::create(unsigned long) (handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/WindowImpl.cpp:78
#12 0x00007ffff7929ac2 in sf::Window::create(unsigned long, sf::ContextSettings const&) (this=0x7fffffffe170, handle=37748752, settings=...) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Window.cpp:141
#13 0x00007ffff74dfc69 in qsf::QSFMLWidget::showEvent(QShowEvent*) () at /usr/lib/libQSFML.so.1
#14 0x00007ffff6e1cef8 in QWidget::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5
#15 0x00007ffff6dd5e0c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#16 0x00007ffff6ddd581 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#17 0x00007ffff6831de0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#18 0x00007ffff6e19b28 in QWidgetPrivate::show_helper() () at /usr/lib/libQt5Widgets.so.5
#19 0x00007ffff6e1c945 in QWidget::setVisible(bool) () at /usr/lib/libQt5Widgets.so.5
#20 0x0000000000403e1a in main ()
//edit3:
Apparently it's all because of sf::Window trying to get events by itself (backtrace #7). It didn't work earlier either, but didn't cause anything like that. However there's no documented way to remove events handling without modifying SFML code. Maybe adding sf::RenderWindow::enableEventProcessing(bool) set to true by default would be good idea? Or some fix in backend, maybe it's all caused by some small mistake in code.