Created attachment 881888 [details] Backtrace Description of problem: See attached backtrace. Version-Release number of selected component (if applicable): qt5-qtbase-5.2.1-7.fc21.x86_64 How reproducible: Very often Steps to Reproduce: 1. Run qt-creator (rawhide version, built against qt5) 2. Open a few files to edit 3. Suspend, resume -> qt-creator has gone
Correction: this actually happens when connecting/disconnecting displays.
Found related QTBUG-38326 too, which is specifically about qt-creator (but probably still the same fundamental issues)
Created attachment 985458 [details] backtrace This is still an issue and now affects the entire plasma5 desktop on rawhide unfortunately. The location where the crash occurs has changed however compared to the originally posted backtrace. A new backtrace is attached (obtained from krunner, but applies to all Qt5 applications).
Created attachment 985534 [details] QXcbClipboard::requestor() backtrace Patchset 2 at https://codereview.qt-project.org/#/c/87885/ seems to prevent the crash in Screen::availableGeometry(), but there is now another crash which happens in QXcbClipboard::requestor(), see attachment.
I take it you're using a patched qtbase build (per the patchset referenced in comment #4)? Would you suggest we pull that into our packaging?
Created attachment 985602 [details] kscreen crash Yes I'm currently using a patched qtbase with that patch. As to whether include that patch set: it appears to fix the issue causing the backtrace posted in comment #3, but as noted in comment #4, the crash now simply happens elsewhere. Plus, I've encountered yet another screen related crash in KScreen (see attachment) which causes plasmashell to die. I'll search further this evening in the hope of managing to do some hacky-patchy to at least have the applications survive the screen change, since the situation at the moment is quite bad. By the way, should this be a F21 blocker?
A F22/plasma5 feature blocker you mean? We can consider it, I'll add it to the plasma5 tracking bug.
Created attachment 985813 [details] Attempt at keeping old screens around (äh right, f22 not f21...) So after looking at the code for a while, I fear that in just so many places there is the assumption that there is always a screen attached to the system. On X11 however, when switching resolutions or changing display configuration, there always appears to be an instant where the system reports no screens attached, leading to NULL pointer dereferences all over. Trying to properly catch all the NULL pointers returned by screen related functions is pretty cumbersome - these pointers can easily travel some way through the codebase before they blow up (and even beyond the Qt5 codebase, for instance if a client application calls some QX11Info methods, these can also return NULL pointers, and looking at the KF5/Plasma5 codebase, I don't see them being handled). So in short, I don't think that's the way to go. What I'm trying to do insteadis to attempt keeping around the old QXcbScreen instances for the period where no screen is attached, see attached patch. The result so far looks promising, in the sense that I don't get any crashes anymore. However, it now happens often after configuration changes that the regions of the screen are pretty messed up (i.e. getting a 1440x900 patch surrounded by artifacts on a 1920x1200 screen etc). (I'm actually not sure whether this is the fault of the xcb code inside Qt5 or whether KScreen is to blame for that - I'll need to do some testing on LxQt to isolate the Qt5 xcb behaviour.) Possibly instead of keeping the old screens a dummy screen should be created with some fake geometry, since keeping around dangling references to non-existing xcb_screen_t is likely a bad idea, even if just for that instance. But in any event, QXcbConnection::updateScreens is probably the best place to work on. Side note: I've also filed #1187324 to stop plasmashell from crashing. KScreen also suffers from the same issue that for an instance no screen is available, leading to crashes because various users of KScreen do not test for NULL. The patch posted there is an attempt to fix one such case, though the underlying issue still remains and very likely affects other code paths as well. I haven't yet investigated whether the KScreen display handling is independent from the Qt5 xcb backend resp. if a dummy display trick could also work there. Perhaps some KScreen developer (Daniel Vrátil?) can give some insight here. This to sum up my findings so far...
Thanks for the update, when you think it's ready for wider feedback, I'd encourage you to submit your findings upstream too.
Created attachment 986297 [details] Patch Patch candidate. See [1] for details. So far, by using lxqt-config-monitor to switch resolutions, things appear to work nicely. As noted in QTBUG-42985, plasmashell (and kwin) occasionally seem to get their geometry messed up, but I suspect this is a kscreen issue. Hope to receive some feedback on this here [2]. [1] https://bugreports.qt.io/browse/QTBUG-42985?focusedCommentId=271750 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1187324#c4
Created attachment 986587 [details] Patch Updated patch. See https://bugreports.qt.io/browse/QTBUG-42985?focusedCommentId=271783 for details. With this now quite large patch things seem stable. plasmashell still seems to get its geometry mixed up after changing screen configuration a number of times though.
Thanks, patch pulled in. %changelog * Sat Jan 31 2015 Rex Dieter <rdieter> 5.4.0-9 - crashes when connecting/disconnecting displays (#1083664,QTBUG-42985)
If you want upstream feedback on that patch, the best way is to submit to: https://codereview.qt-project.org/
I'm planning to, but somehow I'm not able to git clone ssh://codereview.qt-project.org:29418/qt/qtbase.git despite having set up an account with public key... Will look into it. (Oh and their SSL certificate is also expired).
Created attachment 987698 [details] Patch for crash in QXcbConnection::finalizeXInput2 Another related patch to add next time a qt5 build is fired... (Still chasing some issues of regions of windows not updating correctly, suspect due to an invalid geometry somewhere).
Created attachment 990047 [details] backtrace QTBUG-44388 Heads up: some recent changes (possibly the fact that we are now compiling with gcc 5.0?) exposed another ugly issue in Qt5 which causes applications to now crash right on start (honestly I wonder how it ever worked). On Fedora, you'll see backtraces such as the one attached. Upstream issue is [1]. [1] https://bugreports.qt.io/browse/QTBUG-44388
OK, one more to track, this is starting to look like a fun hole to dig
And as soon as you think you fixed an issue turns out it only masked an even worse one which is waiting around the corner, greeting you with a big 0x0 segfault ...
Joy, I think now I've even hit a gcc bug? Program received signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x00007ffff69120ce in QMetaObject::activate(QObject*, int, int, void**) (sender=0x0, signalOffset=8, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffffffd560) at kernel/qobject.cpp:3592 #1 0x00007ffff6913067 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=<optimized out>, m=m@entry=0x7ffff703c280 <QGuiApplication::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffffffd560) at kernel/qobject.cpp:3582 #2 0x00007ffff6bfa8e2 in QGuiApplication::screenAdded(QScreen*) (this=<optimized out>, _t1=0x66caf0) at .moc/moc_qguiapplication.cpp:321 ==> See below, "this" is actually 0x0 here #3 0x00007ffff6bf15c5 in QPlatformIntegration::screenAdded(QPlatformScreen*, bool) (this=<optimized out>, ps=ps@entry=0x66cb10, isPrimary=isPrimary@entry=true) at kernel/qplatformintegration.cpp:447 [...] #13 0x00007ffff68e6f6f in QCoreApplication::init() (this=this@entry=0x650450) at kernel/qcoreapplication.cpp:726 ==> QCoreApplication::self has already been set at this point (QCoreApplication::self = this;) #14 0x00007ffff71aba87 in QApplication::QApplication(int&, char**, int) (this=0x650450, argc=@0x7fffffffdc3c: 1, argv=0x7fffffffde28, _internal=328704) at kernel/qapplication.cpp:565 [...] (gdb) break qplatformintegration.cpp:447 Breakpoint 1, QPlatformIntegration::screenAdded (this=<optimized out>, ps=ps@entry=0x66cb10, isPrimary=isPrimary@entry=true) [...] 447 emit qGuiApp->screenAdded(screen); (gdb) s QGuiApplication::screenAdded (this=0x0, _t1=0x66caf0) at .moc/moc_qguiapplication.cpp:319 (gdb) print QGuiApplication::self $4 = (QCoreApplication *) 0x650450 qGuiApp is #define qGuiApp (static_cast<QGuiApplication *>(QCoreApplication::instance())) with QCoreApplication::instance() returning QGuiApplication::self ==> So "emit qGuiApp->screenAdded(screen);" results in screenAdded being called on a NULL QGuiApplication, but at the same time QGuiApplication::self should be perfectly okay.
*** Bug 1192544 has been marked as a duplicate of this bug. ***
Concerning comment 19: as posted on -devel, this is indeed a GCC bug (specifically, with the gold linker). Workaround is to build qt5 passing -no-use-gold-linker to configure. Filed as [1], but turns out it was a known issue where not much is being done about it. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65057
I filed separate bug for gold issue, bug #1193044
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
marking fixed * Sat Jan 31 2015 Rex Dieter <rdieter> 5.4.0-9 - crashes when connecting/disconnecting displays (#1083664,QTBUG-42985) Subsequent builds should do even better.
Created attachment 1008813 [details] Backtrace There is a regression in qt5-qtbase-5.4.1-6.fc23, "new" crash location when switching display configuration (I can reliably reproduce with lxqt-config-monitor and konsole among others), see attached backtrace.
Correction: regression is since 5.4.1-4, not -6.
* Wed Mar 25 2015 Daniel Vrátil <dvratil> - 5.4.1-4 - pull in set of upstream Qt 5.5 fixes and improvements for XCB screen handling rebased to 5.4 That's where we included all the screen-related backports from 5.5, so something must be wrong there. :(
Yes - if I find a minute I'll try to investigate, perhaps also Daniel Vratil (CCed) could have a look since he authored one of the larger xcb patches.
Hmm, I must have overlooked something during the backport. I'll look into it.
I have reverted the change and removed the XCB patches from qt5-qtbase package. Turned out that I would need to backport couple more patches and with the current set already having 7 patches, adding more and more is really not the way to go. You will have to wait for Qt 5.5 release (scheduled for May currently), sorry.
*** Bug 1232243 has been marked as a duplicate of this bug. ***
Another user experienced a similar problem: This crash happens only, if I've opened project, which used custom Kit and I've clicked the settings menu item. When Desktop Kit is choosen, the settings dialog opens properly. reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: /bin/qtcreator crash_function: QScreen::handle executable: /usr/bin/qtcreator global_pid: 13575 kernel: 4.0.4-303.fc22.x86_64 package: qt-creator-3.4.1-1.fc22 reason: qtcreator killed by SIGSEGV runlevel: N 5 type: CCpp uid: 1000
Created attachment 1039387 [details] File: backtrace
Hmpf, the situation has regressed hard with Qt 5.5, most Qt5 applications again crash after a screen configuration change, or, new symptom: they stop repainting. Plasma is completely unusable after changing screens...
Created attachment 1051381 [details] WIP Patch FWIW, WIP patch, allows plasma and most qt5 apps to survive screen configuration changes. Detailed status: 1. All screens removed before new ones added (fixed) ---------------------------------------------------- - Each time a screen is deleted, the screen of every affected window is set to the primary screen. - When all screens are removed, the primary screen is null: #0 0x00007ffff68459e0 in QWindow::setScreen(QScreen*) (this=this@entry=0x5555559039b0, newScreen=newScreen@entry=0x0) at kernel/qwindow.cpp:1721 #1 0x00007ffff6862ddc in QScreen::~QScreen() (this=0x5555557ba000, __in_chrg=<optimized out>) at kernel/qscreen.cpp:97 - When screens are added again, these windows don't get their screen updated to the new primary screen => Solution: QPlatformIntegration::screenAdded should check for windows with null screen, and place them on the current primary screen 2. Windows are invisible after screen configuration change (fixed) ------------------------------------------------------------------- - In QWindowPrivate::setTopLevelScreen, shouldRecreate is usually true when a screen was on a screen which was removed - When shouldRecreate is true, q->destroy() hides the window and sets visibilityOnDestroy - In QWindowPrivate::setTopLevelScreen, visibilityOnDestroy is queried before q->destroy(), meaning we are using a possibly incorrect value void QWindowPrivate::setTopLevelScreen(QScreen *newScreen, bool recreate) { // [...] if (newScreen != topLevelScreen) { // this is true const bool shouldRecreate = recreate && windowRecreationRequired(newScreen); // unclear when windowRecreationRequired returns true (kscreen dependent?), when it does return true, problems arise const bool shouldShow = visibilityOnDestroy && !topLevelScreen; // this seems wrong, visibilityOnDestroy is set by q->destroy, here we are using an old value. And the reason for !topLevelScreen is also misterious if (shouldRecreate && platformWindow) q->destroy(); // window gets hidden here connectToScreen(newScreen); if (shouldShow) // this should get called but is not due to the value of visibilityOnDestroy being read too early q->setVisible(true); else if (newScreen && shouldRecreate) create(true); // this apparently creates the platform resources but does not show the widget emitScreenChangedRecursion(newScreen); } } => Solution: Rework setTopLevelScreen code 3. Qt-Creator crashes in QScreen::devicePixelRatio() (corrupt QScreen pointer?) ---------------------------------------------------------------------- - Crash at QScreen::devicePixelRatio() const (qscreen.cpp:261) 4. Windows with no contents --------------------------- - Certain windows are displayed with frame only, and no contents (i.e. Digital Clock Settings from plasma taskbar)
(In reply to Sandro Mani from comment #34) > Hmpf, the situation has regressed hard with Qt 5.5, most Qt5 applications > again crash after a screen configuration change, or, new symptom: they stop > repainting. Plasma is completely unusable after changing screens... I already have repaint problems with Qt5.4.2 : after I unplug my external monitor (primary screen, on the right), in applications which were on this screen (at least Konsole, QtCreator, and ktp-text-ui, but not Kate), scrolling only updates the top/bottom lines.
Yes I noticed the scrolling issue as well with 5.4.2, but not yet with 5.5. The "windows with no contents" issue seems more related to plasmashell than Qt5 itself (have not noticed the issue with any other windows than plasma applet configuraiton dialogs). Issues definitely still present with Qt5.5 are some more occurrences of bad QScreen pointers causing crashes.
(In reply to Sandro Mani from comment #37) > Yes I noticed the scrolling issue as well with 5.4.2, but not yet with 5.5. I hope the mouse cursor and hover events are fixed too. > The "windows with no contents" issue seems more related to plasmashell than > Qt5 itself (have not noticed the issue with any other windows than plasma > applet configuraiton dialogs). Did you test with other QtQuick2 applications ? They don't paint like widget ones. With Qt5.4.2 plasma seems to have specific problems too (missing wallpaper, krunner not centered, panel sometimes under windows, ...), but perhaps it's just more sensitive to QScreen position/size issues.
No actually I didn't, could indeed be a general QtQuick problem. And once the core Qt5 issues are tackled, yes, there are many other problems to tackle, in addition to those you mention the fact that if you resume with a different screen configuration, the lock screen will often end up being completely dead and distorted, and you are left with little else to do than kill the whole X session....
You can kill kscreenlocker_greet, it will restart automatically, then you can unlock. It's better than having to kill the whole session. I often have to do it since I have many deadlocks (https://bugzilla.redhat.com/show_bug.cgi?id=1193742).
Ah cool, that's definitely better. Thanks for the tip!
finally got a build to succeed, qt5-qtbase-5.5.0-5.fc23 : http://koji.fedoraproject.org/koji/buildinfo?buildID=668724
Just a remark: the latest patch does not fix all of the problems, crashes are still pretty common unfortunately (mainly QML stuff if seams). So "Fixed In Version: qt5-qtbase-5.5.0-5.fc23" is not really true. I'd also suggest keeping the status to ASSIGNED.
OK, I just wanted to highlight that was the latest testable build
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
(In reply to Loïc Yhuel from comment #38) > (In reply to Sandro Mani from comment #37) > > Yes I noticed the scrolling issue as well with 5.4.2, but not yet with 5.5. > I hope the mouse cursor and hover events are fixed too. Sadly I still have the scrolling and mouse cursor issues with Qt5.5. I did a few other tests. After plugging a second screen : - the panel is at the correct position on the second screen - the maximized windows go under the panel (I remember seeing this issue with Qt5.4.2 sometimes) Restarting plasmashell fixes the issue. After removing the second screen, I got a new bug (perhaps due to how QScreen removal is handled now) : the maximized windows have the correct size, but the panel isn't visible (so I see the desktop at the bottom of the screen). In plasmashell process : - panel position is incorrect : {x1 = 0, y1 = 1050, x2 = 1599, y2 = 1079} (was {x1 = 1600, y1 = 1050, x2 = 3519, y2 = 1079} before the removal, should be {x1 = 0, y1 = 870, x2 = 1599, y2 = 899}) - primary screen geometry is correct : {x1 = 0, y1 = 0, x2 = 1599, y2 = 899}
Sandro, any opinions on how best to handle bug #1291003 ? Seems one of the removed snippets in setParent, @@ -1493,8 +1496,6 @@ void QXcbWindow::setParent(const QPlatfo xcb_parent_id = qXcbParent->xcb_window(); m_embedded = qXcbParent->window()->type() == Qt::ForeignWindow; } else { - if (!xcbScreen()) - return; xcb_parent_id = xcbScreen()->root(); m_embedded = false; } is triggering a lot of user-reported crashes.
Tried reproducing, and can only reproduce with the Breeze theme. With the stock Qt5 fusion theme, I cannot reproduce this. This might actually be the same as #1247967 and #1290993. From the command line output "Attempt to set a screen on a child window." I'd say that breeze is doing something incorrectly, rather than a bug in Qt itself. Valgrind suggests that a uninitialized/corrupt screen pointer is the culprit. 0x561b4fc51160 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc4a910 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc481c0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc4a190 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7d59b0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fcd4e00 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc47920 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fb09a10 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc4a190 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7d59b0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7d5360 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e3300 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7507a0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e8900 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e9110 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8fb6a0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f6c5440 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e7a40 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7adc80 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e9110 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8fb6a0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8e9950 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7b5090 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7c53f0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f901710 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f901f40 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc7f580 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fb887a0 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f8de310 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f7e8580 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f901f40 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4fc7f580 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. 0x561b4f902770 ( QScreen(0x561b4f478e70, name="LVDS1") ): Attempt to set a screen on a child window. [sandro@PC4 bug-1291003]$ valgrind ./filedialogtest -style breeze ==13544== Memcheck, a memory error detector ==13544== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==13544== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==13544== Command: ./filedialogtest -style breeze ==13544== ==13544== Invalid read of size 8 ==13544== at 0x4163408: QXcbWindow::setParent(QPlatformWindow const*) (in /usr/lib64/libQt5XcbQpa.so.5.6.0) ==13544== by 0x55C53D2: QWindow::setParent(QWindow*) (in /usr/lib64/libQt5Gui.so.5.6.0) ==13544== by 0x4FD0084: QWidgetPrivate::setParent_sys(QWidget*, QFlags<Qt::WindowType>) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x4FDB7D4: QWidget::setParent(QWidget*, QFlags<Qt::WindowType>) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x4FDC85B: QWidget::setParent(QWidget*) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x50BE93B: QDialogButtonBox::addButton(QAbstractButton*, QDialogButtonBox::ButtonRole) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x1996B308: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x1996B5E1: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x1995F429: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x518DE04: QDialogPrivate::platformHelper() const (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x51A0E47: QFileDialogPrivate::init(QUrl const&, QString const&, QString const&) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x51A1115: QFileDialog::QFileDialog(QFileDialogArgs const&) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==13544== ==13544== ==13544== Process terminating with default action of signal 11 (SIGSEGV) ==13544== Access not within mapped region at address 0x18 ==13544== at 0x4163408: QXcbWindow::setParent(QPlatformWindow const*) (in /usr/lib64/libQt5XcbQpa.so.5.6.0) ==13544== by 0x55C53D2: QWindow::setParent(QWindow*) (in /usr/lib64/libQt5Gui.so.5.6.0) ==13544== by 0x4FD0084: QWidgetPrivate::setParent_sys(QWidget*, QFlags<Qt::WindowType>) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x4FDB7D4: QWidget::setParent(QWidget*, QFlags<Qt::WindowType>) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x4FDC85B: QWidget::setParent(QWidget*) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x50BE93B: QDialogButtonBox::addButton(QAbstractButton*, QDialogButtonBox::ButtonRole) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x1996B308: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x1996B5E1: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x1995F429: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlatformTheme.so) ==13544== by 0x518DE04: QDialogPrivate::platformHelper() const (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x51A0E47: QFileDialogPrivate::init(QUrl const&, QString const&, QString const&) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== by 0x51A1115: QFileDialog::QFileDialog(QFileDialogArgs const&) (in /usr/lib64/libQt5Widgets.so.5.6.0) ==13544== If you believe this happened as a result of a stack ==13544== overflow in your program's main thread (unlikely but ==13544== possible), you can try to increase the size of the ==13544== main thread stack using the --main-stacksize= flag. ==13544== The main thread stack size used in this run was 8388608. ==13544== ==13544== HEAP SUMMARY: ==13544== in use at exit: 4,990,650 bytes in 36,591 blocks ==13544== total heap usage: 285,074 allocs, 248,483 frees, 104,478,310 bytes allocated ==13544== ==13544== LEAK SUMMARY: ==13544== definitely lost: 36 bytes in 1 blocks ==13544== indirectly lost: 0 bytes in 0 blocks ==13544== possibly lost: 11,696 bytes in 189 blocks ==13544== still reachable: 4,978,918 bytes in 36,401 blocks ==13544== of which reachable via heuristic: ==13544== newarray : 6,344 bytes in 33 blocks ==13544== multipleinheritance: 186,544 bytes in 253 blocks ==13544== suppressed: 0 bytes in 0 blocks ==13544== Rerun with --leak-check=full to see details of leaked memory ==13544== ==13544== For counts of detected and suppressed errors, rerun with: -v ==13544== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Fwiw, if it matters, I'm using Qt 5.6.0beta, and I get a lot of "Attempt to set a screen on a child window." warnings (without crashes), using both breeze and fusion: $ kate -style fusion ... 0x5653d91dd1e0 ( QScreen(0x5653d8be9ec0, name="LVDS1") ): Attempt to set a screen on a child window. 0x5653d91f6f30 ( QScreen(0x5653d8be9ec0, name="LVDS1") ): Attempt to set a screen on a child window. 0x5653d91fbff0 ( QScreen(0x5653d8be9ec0, name="LVDS1") ): Attempt to set a screen on a child window. ... I suppose we should be commenting on bug #1291003 too :) , if you're confident the problem lies elsewhere
Uh, that's odd, I get no "Attempt to set a screen on a child window." at all using fusion. I'm having a glance at the kf5-frameworkintegration code to check my theory...
(qt5-qtbase-5.6.0-0.17.beta.fc24.x86_64 here fwiw)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.