Summary: | Okular presentation mode fails | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Chris Sims <cas> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | nr.12345, roman.cheplyaka, sandys |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | proposed fix |
Description
Chris Sims
2009-01-10 22:12:35 UTC
The "Installed from: Compiled sources" line is incorrect, placed there by the bug reporting wizard. I chose that because there was no option to report kde 4.1.85 or 4.2 Beta 2. I am using binaries from a .deb package. The backtrace you provided is of no use; you can get a better one by following the instructions written in: http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports Also, please read bug #172894. I've installed .dbg packages (couldn't find one for libqtgui4) and obtained the hopefully more useful backtrace below. Also, I found that the fix from bug 172894, eliminating the "Okular initial default size" line from the system settings -> Window behavior -> Window Specific list corrected the problem. I could not make the problem reappear by recreating the "Okular initial default size" line in that list, though. I neglected to copy the exact settings, so I mimicked those for the "Kate initial default size". Those seemed not to produce a problem. I then created a new user, logged in as that user, and reproduced the problem. However, I now see that clicking the upper right corner of the window does not always produce a crash. Sometimes a red button appears under the cursor and the application then closes normally. Clicking the other parts of the screen makes a "0" appear in the upper right where the page number should appear, and clicking the 0 sometimes causes a crash. Also, in one of my experiments the document appeared in the window that was created by the presentation command. This only happened once, and I could not reproduce it. Application: Okular (okular), signal SIGABRT Thread 1 (Thread 0xb601f8d0 (LWP 14768)): [KCrash Handler] #6 0xb7f10430 in __kernel_vsyscall () #7 0xb66dc880 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb66de248 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7285795 in qt_message_output () from /usr/lib/libQtCore.so.4 #10 0xb7285872 in qFatal () from /usr/lib/libQtCore.so.4 #11 0xb72858cc in qt_assert_x () from /usr/lib/libQtCore.so.4 #12 0xb49d6559 in PresentationWidget::changePage (this=0x911bd00, newPage=0) at /usr/include/qt4/QtCore/qvector.h:325 #13 0xb49d7613 in PresentationWidget::mousePressEvent (this=0x911bd00, e=0xbfc0fc08) at /build/buildd/kdegraphics-4.1.85/okular/ui/presentationwidget.cpp:460 #14 0xb6ac5949 in QWidget::event () from /usr/lib/libQtGui.so.4 #15 0xb49d0b93 in PresentationWidget::event (this=0x911bd00, e=0xbfc0fc08) at /build/buildd/kdegraphics-4.1.85/okular/ui/presentationwidget.cpp:393 #16 0xb6a6d8ec in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #17 0xb6a760e1 in QApplication::notify () from /usr/lib/libQtGui.so.4 #18 0xb791ad3d in KApplication::notify (this=0xbfc1051c, receiver=0x911bd00, event=0xbfc0fc08) at /build/buildd/kde4libs-4.1.85/kdeui/kernel/kapplication.cpp:307 #19 0xb737de61 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #20 0xb6a7536e in QApplicationPrivate::sendMouseEvent () from /usr/lib/libQtGui.so.4 #21 0xb6adf656 in ?? () from /usr/lib/libQtGui.so.4 #22 0xb6ade9e5 in QApplication::x11ProcessEvent () from /usr/lib/libQtGui.so.4 #23 0xb6b087aa in ?? () from /usr/lib/libQtGui.so.4 #24 0xb63556f8 in IA__g_main_context_dispatch (context=0x8d0e898) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2144 #25 0xb6358da3 in g_main_context_iterate (context=0x8d0e898, block=1, dispatch=1, self=0x8d0c378) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2778 #26 0xb6358f61 in IA__g_main_context_iteration (context=0x8d0e898, may_block=1) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2841 #27 0xb73a8478 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #28 0xb6b07ea5 in ?? () from /usr/lib/libQtGui.so.4 #29 0xb737c52a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #30 0xb737c6ea in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #31 0xb737eda5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #32 0xb6a6d767 in QApplication::exec () from /usr/lib/libQtGui.so.4 #33 0x0804e487 in main (argc=) at /build/buildd/kdegraphics-4.1.85/okular/shell/main.cpp:81 Does the problem still happen with KDE 4.2 final? I confirm that this bug exists in: Okular Version 0.8 Using KDE 4.2.00 (KDE 4.2.0) (installed from Arch package) This also happens with every document I try. @Roman Cheplyaka:
> I confirm that this bug exists in:
> [...]
> This also happens with every document I try.
Please do provide an useful backtrace.
Application: Okular (okular), signal SIGABRT Thread 1 (Thread 0xb6320a60 (LWP 14266)): [KCrash Handler] #6 0xb8007424 in __kernel_vsyscall () #7 0xb6af3720 in raise () from /lib/libc.so.6 #8 0xb6af5058 in abort () from /lib/libc.so.6 #9 0xb74da815 in qt_message_output () from /usr/lib/libQtCore.so.4 #10 0xb74da8c6 in qFatal () from /usr/lib/libQtCore.so.4 #11 0xb74da90c in qt_assert_x () from /usr/lib/libQtCore.so.4 #12 0xb4a2dce5 in QVector<PresentationFrame*>::operator[] () from /usr/lib/kde4/okularpart.so #13 0xb4a28a59 in PresentationWidget::changePage () from /usr/lib/kde4/okularpart.so #14 0xb4a29d5e in PresentationWidget::mouseMoveEvent () from /usr/lib/kde4/okularpart.so #15 0xb6e9bbb0 in QWidget::event () from /usr/lib/libQtGui.so.4 #16 0xb4a2a2f7 in PresentationWidget::event () from /usr/lib/kde4/okularpart.so #17 0xb6e49aec in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #18 0xb6e50863 in QApplication::notify () from /usr/lib/libQtGui.so.4 #19 0xb7ac8f2d in KApplication::notify () from /usr/lib/libkdeui.so.5 #20 0xb75bbf31 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #21 0xb6e51be3 in QApplicationPrivate::sendMouseEvent () from /usr/lib/libQtGui.so.4 #22 0xb6eae715 in ?? () from /usr/lib/libQtGui.so.4 #23 0x0a30efe8 in ?? () #24 0xbfc21a0c in ?? () #25 0x00000000 in ?? () (this is what I got compiling debug version od kdegraphics. I think the reason is that "cmake install" seems to strip binaries independently of CMAKE_BUILD_TYPE) Also it prints ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/QtCore/qvector.h, line 325 to the terminal. I also can confirm the problem persists in KDE 4.2 final. I have found two workarounds. One is to simply delete the "Okular initial default size" line in System Settings -> Window Behavior -> Window-Specfic. The other is to modify the "Okular initial default size" setting by checking "Match Whole Window Class". With either change, Okular properly opens a full-screen presentation mode, and so far I have found no negative side effects from the changes. My previous report that deleting "Okular initial default size", then recreating it to match the corresponding Kate setting, eliminated the problem was incorrect. I had checked "Match whole window class" in recreating the Okular setting (and the Kate setting does not check "Match whole window class"). If the problem is related to kubuntu and to that broken rule, then your bug is #182921. Although Roman Cheplyaka is not using kubuntu, so I guess that broken rule does not apply. Chris Sims: thanks for your comment! Now it's clear that okular's presentation mode has problems with window manager which gives the presentation window other size than it requested. Personally I use tiling window manager (xmonad), which itself calculates window size. If I add a rule that floats okular (i.e. does not tile it), presentation shows ok. This explains why most of users do not observe this bug -- they use non-tiling window managers (like kwin). BTW, just installed kdegraphics 4.2.1 and the bug is still there. (In reply to comment #10) > Chris Sims: thanks for your comment! Now it's clear that okular's presentation > mode has problems with window manager which gives the presentation window other > size than it requested. Actually this is not true: Okular just request a size, but it does listen to the resize events the window manager (and adapts to them). It really does react on resize after it's opened in floating mode. It even works when it's made tiled again. But if it's tiled from the beginning then the above behaviour is observed. @Roman: are you able to try the following patch? (either 4.2 or trunk is okay) Index: ui/presentationwidget.cpp =================================================================== --- ui/presentationwidget.cpp (revision 935675) +++ ui/presentationwidget.cpp (working copy) @@ -640,10 +640,6 @@ void PresentationWidget::resizeEvent( QResizeEvent *re ) { - // kDebug() << re->oldSize() << "=>" << re->size(); - if ( re->oldSize() == QSize( -1, -1 ) ) - return; - m_screen = QApplication::desktop()->screenNumber( this ); applyNewScreenSize( re->oldSize() ); With this patch presentation does not work even with "floating" workaround (symptoms are as described in original post). Hmm... ok. Attempt #2 then: Index: ui/presentationwidget.cpp =================================================================== --- ui/presentationwidget.cpp (revision 935675) +++ ui/presentationwidget.cpp (working copy) @@ -230,6 +230,8 @@ // inhibit the screen saver inhibitScreenSaver(); + show(); + QTimer::singleShot( 0, this, SLOT( slotDelayedEvents() ) ); } @@ -373,6 +375,7 @@ // <widget events> bool PresentationWidget::event( QEvent * e ) { +kDebug() << e << e->spontaneous(); if ( e->type() == QEvent::ToolTip ) { QHelpEvent * he = (QHelpEvent*)e; In this case, also remember to activate the okular debug areas in kdebugdialog; then activate the presentation mode, go forward let's say 2-3 pages, and then close it. Attach the output you get. Created attachment 31883 [details] proposed fix Uh interesting, 10 minutes after posting the attempt #2 and keeping trying, I seemed to got the same problem. Romain, could you please forget the previous attempts and trying this one? (In case it works, can you verify also bug #186464?) Yes, it fixes the issue for me, thanks. OTOH it has no impact on bug #186464. SVN commit 936560 by pino: make sure to attach to the document also when a resize event is received prior of a paint event, hopefully fixing #180291 thanks Roman Cheplyaka for the testing! BUG: 180291 M +13 -6 presentationwidget.cpp M +1 -0 presentationwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=936560 SVN commit 936561 by pino: backport: make sure to attach to the document also when a resize event is received prior of a paint event will be in KDE 4.2.2 CCBUG: 180291 M +13 -6 presentationwidget.cpp M +1 -0 presentationwidget.h WebSVN link: http://websvn.kde.org/?view=rev&revision=936561 *** Bug 184976 has been marked as a duplicate of this bug. *** *** Bug 182906 has been marked as a duplicate of this bug. *** |