Summary: | Oxygen crashes the Red Eye reduction kipi plugin | ||
---|---|---|---|
Product: | [Plasma] Oxygen | Reporter: | András Manţia <amantia> |
Component: | style | Assignee: | Camilla Boemann <cbo> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andresbajotierra, caulier.gilles, hugo.pereira.da.costa |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
András Manţia
2009-12-12 20:25:36 UTC
- What are your KDE svn revision and Qt git revision (just to have a reference)? Thanks trunk, respectively Qt 4.6 branch from some days ago. And happens with today's trunk/4.6 branch as well.Same for bug 218417 . As for the infinite loop, obviously I didn't paste the whole backtrace as that would be just too long. See this: #142 0x00007ffff7b1403c in Digikam::EditorWindow::slotZoomChanged something (Digikam::Canvas::resizeEvent) triggered the slotZoomChanged. This calls d->zoomCombo->setCurrentIndex(-1); a setCurrentIndex on a QComboBox. This causes the Digikam::Canvas::resizeEvent to be called again (#107) that triggers again slotZoomChanged (#97). Now not the setCurrentIndex, but a following setEditText is called (#96): d->zoomCombo->setEditText(QString::number(lround(zoom*100.0)) + QString("%")); This again triggers a Digikam::Canvas::resizeEvent (#63) ending in slotZoomChanged(#53) calling setCurrentIndex on the QComboBox and we're back at the start: an infinite loop. The app crashes quickly because of stack overflow. The resizeEvent seems to be initiated from Oxygen::TransitionWidget::grab calling QPixmap::grabWidget. I think (without looking at the code) it is either because grabWidget causes a resize or because it causes sending of pending events (QWidgetPrivate::sendPendingMoveAndResizeEvents) and the event queue still has the resize event caused by the setCurrentIndex or setEditText, assuming they modify the combo's lineedit size. SVN commit 1062798 by hpereiradacosta: Added flag to prevent recursive call to TransitionWidget::grab, when the latter triggers resizeEvents CCBUG: 218425 M +10 -3 oxygenlineeditdata.cpp M +4 -0 oxygenlineeditdata.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1062798 @András: thanks a lot for deciphering the crash log. Although I could not reproduce the problem here, I might have found an issue in the LineEditor animation logic. (see comment #5). Could you tell me if the crash still occurs after you update ? For the record: OxygenTransitionWidget does not call any resize event directly. But QWidget::render (which it calls) does. And possibly this one was retriggering itself recursively (via oxygen). Waiting for your input ... Unfortunately, it still crashes with today's trunk. argh Interestingly enough, the crash seems to disappear if I use "official" Qt 4.6 (from http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.0.tar.gz) as opposed to kde-qt (from git) ... Not sure whether it's telling anything or not ... Can anyone confirm ? SVN commit 1063312 by hpereiradacosta: added more checks to prevent recursive call to widget::render BUG: 218425 M +37 -12 oxygenlineeditdata.cpp M +8 -10 oxygenlineeditdata.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1063312 @András This time I'm pretty sure that fixes it (actually: the same bug was also crashing the 'hot pixel' effect. Reason is that I could reproduce the crash (although without crash report from Dr Konqui and no backtrace, just pure segfault), then using simple text debug output could target the infinite loop, and the commit fixes it. Now, well, fill free to reopen if you still have the issue (or a similar one) on your side. Works fine now, thank you! Of course, here it also segfaulted without getting a backtrace, you had to run digikam in gdb to be able to generate the backtrace. |