Bug 83320 - Mutex destroy failure on application exit
Summary: Mutex destroy failure on application exit
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-13 21:48 UTC by tops
Modified: 2005-01-19 04:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tops 2004-06-13 21:48:04 UTC
Version:           4.2.1 (using KDE KDE 3.2.3)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc (GCC) 3.3.3 (Debian 20040422 
OS:                Linux

Every time i close a kde application, i am greeted by this annoying message:

Mutex destroy failure: Device or resource busy
ICE default IO error handler doing an exit(), pid = 24962, errno = 2

Now, the application doesn't crash or anything, and exits fine.  But after a few moments i get the above error.  It might be harmless, but its extremely annoying when you're trying to work on the console with a large command and that error shows up all of a sudden to ruin everything.

Thanks.
Comment 1 Anders Lund 2004-06-13 22:21:57 UTC
I cant see how this is related to Kate.
Comment 2 tops 2004-06-14 04:51:03 UTC
sorry about that.  I had thought i selected kwrite, but i guess that would be wrong too.  Thx for changing it.
Comment 3 christophe 2004-08-13 22:45:08 UTC
 Hi,
 This is general in whole KDE, and seems to be related to the Debian packaging: I have exactly the same setup as Tops, and the same problem for every application (kate, konqueror, kooka...).  
 It seems to make kdm unusable, although I'm not sure this is not another bug.
Comment 4 christophe 2004-08-14 13:39:45 UTC
 It seems to be solved by upgrading more or less anything of KDE from Unstable which is not in Sarge.  You may want to try with less packages, I didn't test everything worked after that.
 Anyway, this is a Debian problem: kde 3.2.3 main packages are only partially in Sarge, and mixing different versions is not a good thing to do.

 The command line for me was:
apt-get install -t unstable noatun/unstable k3blibs/unstable k3b/unstable kaddressbook/unstable karbon/unstable kdegraphics-kfile-plugins/unstable kdemultimedia-kfile-plugins/unstable kdelibs-data/unstable kdepim-kfile-plugins/unstable kdepim-kio-plugins/unstable kdict/unstable  kdvi/unstable kghostview/unstable koffice-libs/unstable knode/unstable knewsticker/unstable kmrml/unstable kmix/unstable kmid/unstable kontact/unstable kooka/unstable kopete/unstable kpilot/unstable kpdf/unstable korganizer/unstable  kpovmodeler/unstable kpresenter/unstable krec/unstable kregexpeditor/unstable krfb/unstable arson/unstable  icewm-themes/unstable kaboodle/unstable kbear/unstable  ksplash/unstable ksmserver/unstable kspread/unstable ksvg/unstable ksysguard/unstable kview/unstable kuickshow/unstable kugar/unstable kword/unstable  kuickshow/unstable  kword/unstable
Comment 5 Gregorio Guidi 2005-01-12 11:52:17 UTC
I took a few hours to investigate this issue (which is also at bug 87151, bug 92226, 95698), here's what I found:

in general it happens when an application needs to launch an instance of dcopserver at startup (because it's not already running), the errors are printed at the time the dcopserver decides to shutdown itself and the other kde processes (there's a timeout of 10 seconds).

The first error: "Mutex destroy failure: Device or resource busy" happens becuase 'klauncher' uses the following code to shutdown itself:
(kdelibs/kinit/klauncher.cpp, line ~239)

  delete kapp;
  ::exit(exit_code);

so, it deletes its instance of KApplication while it is in the event loop, with the Qt mutex locked. I could make the error disapear by doing

  kapp->unlock()
  delete kapp;
  ::exit(exit_code);

or by not deleting kapp (is it essential to do it before exiting?), just doing

  ::exit(exit_code);

anyway, you certainly know better that me what should be done at this point.

The second error: "ICE default IO..." is totally unrelated:
it happens because at the time the dcopserver closes itself, the 'kded' process is still connected. I don't know precisely why it's just kded that does not closes its connection in clean way... however the following patch solves the issue and shows that the reason is exactly that.
Again, you know better than me what a more appropriate solution could be.

RCS file: /home/kde/kdelibs/kded/kded.cpp,v
retrieving revision 1.100
diff -u -B -r1.100 kded.cpp
--- kded/kded.cpp       9 Dec 2004 13:16:18 -0000       1.100
+++ kded/kded.cpp       12 Jan 2005 10:49:09 -0000
@@ -696,7 +696,11 @@
 {
 public:
   KDEDApplication() : KUniqueApplication( )
-    { startup = true; }
+    {
+       startup = true;
+       dcopClient()->connectDCOPSignal( "DCOPServer", "", "terminateKDE()",
+                                        objId(), "quit()", false );
+    }

   int newInstance()
     {
Comment 6 tops 2005-01-13 03:14:14 UTC
I would like to say that the problem is still around in kde 3.3.1 (debian unstable). Haven't tried the patches above since i am not sure how to apply patches to source and am afraid that they might break the whole thing.
Comment 7 Waldo Bastian 2005-01-17 23:12:30 UTC
CVS commit by waba: 

Get rid of "Mutex destroy failure: Device or resource busy" by not deleting kapp
CCBUG: 83320


  M +7 -1      klauncher.cpp   1.102


--- kdelibs/kinit/klauncher.cpp  #1.101:1.102
@@ -221,4 +221,9 @@ KLauncher::KLauncher(int _kdeinitSocket)
 KLauncher::~KLauncher()
 {
+   close();
+}
+
+void KLauncher::close()
+{
    if (!mPoolSocketName.isEmpty())
    {
@@ -236,5 +241,6 @@ void
 KLauncher::destruct(int exit_code)
 {
-   delete kapp;
+   if (kapp) ((KLauncher*)kapp)->close();
+   // We don't delete kapp here, that's intentional.
    ::exit(exit_code);
 }


Comment 8 Waldo Bastian 2005-01-17 23:40:22 UTC
*** Bug has been marked as fixed ***.
Comment 9 tops 2005-01-19 04:32:13 UTC
cool, thx.  I look forward to not seeing that anoying error anymore.  Strange that it took 4+ months to get fixed, but hey, i'll take it.