Created attachment 55349 [details] VG log Version: 0.5.81 (using KDE 4.5.90) OS: Linux Hello Probably known problem but I couldn't find this warning on quick bz search. Error: Expected the optional content group list, but wasn't able to find it, or it isn't an Array okular(22218)/kdeui (kdelibs): Attempt to use QAction "" with KXMLGUIFactory! okular(22218)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. Reproducible: Always Steps to Reproduce: open some pdf OS: Linux (x86_64) release 2.6.34.7-0.5-desktop Compiler: gcc
I am seeing this with okular 0.11.80 with KDE 4.5.85 as well. Disabling all debug output in KDebugDialog does not silence this annoying jabber that clogs my terminals.
Adding David as it is a warning he introduced recently. David, i can "fix" this by doing Index: shell/shell.cpp =================================================================== --- shell/shell.cpp (revision 1214938) +++ shell/shell.cpp (working copy) @@ -42,6 +42,7 @@ #include <ktoggleaction.h> #include <ktogglefullscreenaction.h> #include <kactioncollection.h> +#include <kxmlguifactory.h> // local includes #include "kdocumentviewer.h" @@ -118,8 +119,12 @@ Shell::~Shell() { - if ( m_part ) writeSettings(); - delete m_part; + if ( m_part ) + { + writeSettings(); + factory()->removeClient( m_part ); + delete m_part; + } if ( m_args ) m_args->clear(); } But i feel it is somehow weird i have to call factory()->removeClient( m_part ); when i never called addClient(). Is the warning too aggressive? Or do we really ahve to call removeClient before deleting our parts?
okular(7862)/kdeui (kdelibs): Attempt to use QAction "" with KXMLGUIFactory! okular(7862)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0xfacc28 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. $ okular --version Qt: 4.7.1 KDE: 4.6.00 (4.6.0) Okular: 0.12 Archlinux
This should be handled by whatever code is doing the adding not okular. It fact this should be done at the time the warning is given even if a warning message must still be displayed. This is how android handles issues of this nature. The system makes the correction for the issue for the sake of stability but still complains because the real fix needs to be done elsewhere.
Ignore the last part of that comment.
Excerpt from kxmlguiclient.cpp at the source of the warning: if ( d->m_factory ) { kWarning(240) << this << "deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes."; d->m_factory->forgetClient(this); } Considering that the removal is autpmaticly done the warning is a bit too strong. There won't be any stability or leak issues as long as the library performs the removal.
(In reply to comment #4) > This should be handled by whatever code is doing the adding not okular. In case this helps, here is a backtrace from my Gentoo system of where the adding was done for the object whose address is named in the error message: #0 KXMLGUIClient::setFactory (this=0x6e9f68, factory=0x80e610) at kdelibs-4.6.2/kdeui/xmlgui/kxmlguiclient.cpp:599 #1 0x00007ffff73a38cf in KXMLGUIFactory::addClient (this=0x80e610, client=0x6e9f68) at kdelibs-4.6.2/kdeui/xmlgui/kxmlguifactory.cpp:274 #2 0x00007ffff7bb7804 in KParts::MainWindow::createGUI (this=0x702e50, part= 0x6e9cf0) at kdelibs-4.6.2/kparts/mainwindow.cpp:126 #3 0x000000000040a5c4 in Shell::init (this=0x702e50) at okular-4.6.2/okular/shell/shell.cpp:96 #4 0x000000000040a91e in Shell::Shell (...) at okular-4.6.2/okular/shell/shell.cpp:61 #5 0x0000000000408bd0 in main (...) at okular-4.6.2/okular/shell/main.cpp:72 I couldn't say which of these should be responsible for the cleanup, though.
See https://bugs.kde.org/show_bug.cgi?id=266538 as well. This bug is similar to that one a might be a duplicate.
I wrote "this will leak" for a good reason. It does leak, forgetClient() can only do some basic cleanup (forgetting this client, like the name says) but not delete associated containers, that caused crashes (e.g. when they were being deleted already).
Since this apparently cann't be handled by the library the patch mettioned here would seem to be the only opition.
*** Bug 271052 has been marked as a duplicate of this bug. ***
Why is this warning printed out even if though I turn off debugging output in kdebugdialog? Can it be turned off by editing my kdebugrc?
The fix has been known for 5 months now. Please fix it. Polish the fix later, if necessary.
David, can you confirm that i should be calling factory()->removeClient( m_part ); even if i never called addClient()?
The logical place to do this would seem to me to be in kparts/mainwindow.cpp. I am testing a patch to KParts::~MainWindow. Hopefully this doesn't cause problems. Would still like to here back from David on this.
you may know this, but opening a file in kate from the command line does this also, kubuntu 11.04
The kate issue is fixed now in the KDE ppa. Don't know if its been pushed out on any other stable releases yet. kate had mutiple bugs with its own code where it called addClient but did not call removeClient. What I was trying didn't stop the message for Okular. I didn't look to much at why.
*** Bug 283942 has been marked as a duplicate of this bug. ***
*** Bug 288650 has been marked as a duplicate of this bug. ***
The bug continues in the latest release from Fedora-16, namely okular-4.7.4-1.fc16.x86_64. A message like: okular(3746)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x293f978 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. Shows up on the console whenever okular is run from the console.
*** Bug 295358 has been marked as a duplicate of this bug. ***
I'm using Ubuntu 11.10 with okular version 4:4.7.4-0ubuntu0.1 and also have the same issue. In fact, everytime I open a file (png, pdf, ...) in okular I get this messages: okular(16596)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(16596)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(16596)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: And when I close the window I get the famous okular(16596)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x15a4938 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. Ubuntu 11.10 Linux 3.0.0-16-generic x86_64
*** Bug 295005 has been marked as a duplicate of this bug. ***
I'm also seeing this exact issue on Ubuntu 11.10. Would like to know how to fix it. For now I'm not running okular from the terminal, but this is an annoyance. Also, I'm not sure if running it from the GUI actually resolves the problem, or if it just doesnt report it the way the terminal does.
In KDE 4.8.3 I'm only seeing the "deleted without having been removed from the factory first" message, and only when I quit Okular.
Fedora 17, AMD64 These error messages appear on the console that launched XFCE4 (startx). Okular, Ark. Common tags: "/kdeui (kdelibs)" I stumbled about among the kdeui sources and noticed the warning comes from the destructor KXMLGUIClient::~KXMLGUIClient() which deletes the m_parents. Perhaps there is a possible race condition with the factory destructor KXMLGUIFactory::~KXMLGUIFactory() which deletes the m_client instances? Pardon my feeble grasp of the code, just looking for possible ways the Client and Factory destructors could interact.
Qt GUI code runs in a single thread, there can't be race conditions. This is about removeClient() not being called, after addClient(). However I don't understand comment #14, if you never call addClient(), then I'm missing a piece of the puzzle (who adds the client?).
(In reply to comment #27) > if you never call addClient(), then I'm > missing a piece of the puzzle (who adds the client?). I have no clue, something in kdelibs?
(In reply to comment #28) > (In reply to comment #27) > > if you never call addClient(), then I'm > > missing a piece of the puzzle (who adds the client?). > > I have no clue, something in kdelibs? That would seem to be indicated by comment 7. There's a stack trace there that should shed some light.
Moving to kdelibs, as Michael says, it is obvious in comment 7 that the addClient call is done by KParts::MainWindow::createGUI, so it is KParts::MainWindow that should care about calling removeClient too
Git commit 4eee1f34793076d3f7ab4dccff87724806da6141 by Albert Astals Cid. Committed on 12/08/2012 at 13:50. Pushed by aacid into branch 'KDE/4.9'. Do not delete the Part on the Shell destructor The machinery in KParts/QObject is already doing it and this way we don't get the KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. warning I'm not sure if calling this a kdelibs bug yet or not though :D FIXED-IN: 4.9.1 M +1 -1 shell/shell.cpp http://commits.kde.org/okular/4eee1f34793076d3f7ab4dccff87724806da6141
Git commit 035c32996ea45aa682db1d18460606ef12c5e6b3 by Albert Astals Cid. Committed on 12/08/2012 at 13:50. Pushed by aacid into branch 'master'. Do not delete the Part on the Shell destructor The machinery in KParts/QObject is already doing it and this way we don't get the KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. warning I'm not sure if calling this a kdelibs bug yet or not though :D FIXED-IN: 4.9.1 M +1 -1 shell/shell.cpp http://commits.kde.org/okular/035c32996ea45aa682db1d18460606ef12c5e6b3
patch works for 4.8.5. too
4.8.x is dead development wise, distributions are free to do as they please under their responsability :-)
This patch causes Okular to spin in the background (consuming 100% CPU) after I've closed it and the window vanished. This happens when I open a pdf and close it (almost) immediately. "perf top" shows: 47.83% libQtCore.so.4.8.2 [.] QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) 15.58% libQtCore.so.4.8.2 [.] QMutex::unlock() 14.04% libokularcore.so.1.9.0 [.] Okular::Document::closeDocument() 13.35% libQtCore.so.4.8.2 [.] QMutex::lock(
Good catch! Can you please update your okular git checkout and make sure my commit fixes the problem you are experimenting?
(In reply to comment #36) > Good catch! Can you please update your okular git checkout and make sure my > commit fixes the problem you are experimenting? Yes everything works as expected again. Thanks for the quick fix.
(In reply to comment #35) > This happens when I open a pdf and close it (almost) immediately. Right - same for 4.8.5. If okular is started on the command line, it can be "closed" via ctrl-C. Because the patch of #comment 32 imade its ways into the Gentoo repository /me wonders where there's a fix for this patch mentioned in #comment 36 ?
https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/aa042bd0f416edfb0eedcac6be6ba90b1c1c161c https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/d41f00e4bb142e07584ab25e7623e485b7f4e458 depending on which branch you want
Moving it back to okular since at the end the codechange was done there, i'm not enterely sure whose fault it is, but who cares :D
*** Bug 305726 has been marked as a duplicate of this bug. ***