Bug 87244 - juk crashes with KDE logout
Summary: juk crashes with KDE logout
Status: RESOLVED FIXED
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.1
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-15 11:44 UTC by prudek
Modified: 2004-09-19 10:34 UTC (History)
0 users

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 prudek 2004-08-15 11:44:44 UTC
Version:           2.1 (using KDE 3.3.0, compiled sources)
Compiler:          gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
OS:                Linux (i686) release 2.4.22-36mdk

This bug is similar to 87051, but it happens for juk 2.1 and a source compiled KDE 3.3 beta 2

When juk is running and you quit KDE, a crash report appears for juk. User has to click a button in order to dismiss the crash report and continue with logout.

This problem was NOT present in KDE 3.2.2
Comment 1 Scott Wheeler 2004-08-15 13:10:19 UTC
Please see the directions in #87051 for getting a backtrace and include on here.  It's almost impossible to debug crashes without them.
Comment 2 prudek 2004-08-15 13:28:20 UTC
I tried to follow your directions #87051 for getting a backtrace but it did now work. Probably there is some step missing. Something that is too obvious for you to remember mentioning it.

- Opened konsole.
- Typed screen <enter>
- Typed gdb juk <enter>
- gdb copyright and "(gdb)" prompt appeared. That's all. juk DID NOT START AT ALL.

Now your instructions say "logout". I did not know whether I should close gdb and Konsole  before logging out. I decided that I should NOT. So I let the logout process kill my Konsole with screen and gdb. Then I logged back in and types "screen -r". The gdb session appeared with gdb prompt and no useful info.
Comment 3 Scott Wheeler 2004-08-15 13:32:10 UTC
Ah, yes -- you need to type "run" to start it in gdb.
Comment 4 prudek 2004-08-15 13:42:18 UTC
OK. Here's what I did.
(gdb) run
Starting program: /usr/kde3.3/bin/juk

Program exited normally.


You see that gdb says "Program exited normally." But juk is in fact running. It DID NOT EXIT. But gdb thinks it exited. 

What should I do now.
Comment 5 Scott Wheeler 2004-08-15 13:52:25 UTC
Heh -- sorry forgot one more thing.  For running in gdb you have to pass the "--nofork" parameter, so instead of "run" use "run --nofork".

Also, note that it's considered rude to use all caps; you're perfectly clear without that.  ;-)
Comment 6 prudek 2004-08-15 19:22:30 UTC
OK. Sorry about capitals. Here's the gdb output:
===
Starting program: /usr/kde3.3/bin/juk --nofork
kio (KDirWatch): Can't use FAM (fam daemon not running?)
kio (KDirWatch): Available methods: Stat
kio (KDirWatch): addDir - recursive/watchFiles not supported in KDE 3.0
kio (KDirWatch): Added Dir /home/nobackup/mp3burned [KDirWatch-1]
kio (KDirWatch): Global Poll Freq is now 500 msec
kio (KDirWatch):  Started Polling Timer, freq 500
kio (KDirWatch):  Setup Stat (freq 500) for /home/nobackup/mp3burned
juk: [virtual void StatusLabel::updateData()]
kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-milos/ksycoca
juk: [virtual void StatusLabel::updateData()]
juk: [virtual void StatusLabel::updateData()]
juk: [virtual void StatusLabel::updateData()]
juk: [virtual void StatusLabel::updateCurrent()]
juk: [virtual void StatusLabel::updateData()]
kio (KDirWatch):  Stopped Polling Timer
kio (KDirWatch): Removed Dir /home/nobackup/mp3burned [KDirWatch-1]
kio (KDirWatch): Poll Freq now 3600000 msec

Program received signal SIGSEGV, Segmentation fault.
0x624f7473 in ?? ()
===

Is it helpful?
Comment 7 Scott Wheeler 2004-08-18 03:05:20 UTC
Close -- but you still didn't type "backtrace" to get a backtrace when it crashed.
Comment 8 prudek 2004-08-19 17:39:17 UTC
Sorry. Here it is:

(gdb) backtrace
#0  0x624f7473 in ?? ()
#1  0x08086345 in PlayerManager::qt_invoke(int, QUObject*) ()
#2  0x412503c7 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#3  0x412501c3 in QObject::activate_signal(int) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#4  0x40b30cc5 in KAction::activated() () from /usr/kde3.3/lib/libkdeui.so.4
#5  0x40b3027c in KAction::slotActivated() ()
   from /usr/kde3.3/lib/libkdeui.so.4
#6  0x40b30252 in KAction::activate() () from /usr/kde3.3/lib/libkdeui.so.4
#7  0x0808044f in JuK::queryExit() ()
#8  0x40b87f55 in KMainWindow::shuttingDown() ()
   from /usr/kde3.3/lib/libkdeui.so.4
#9  0x40b88819 in KMainWindow::qt_invoke(int, QUObject*) ()
   from /usr/kde3.3/lib/libkdeui.so.4
#10 0x08080879 in JuK::qt_invoke(int, QUObject*) ()
#11 0x412503c7 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#12 0x412501c3 in QObject::activate_signal(int) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#13 0x40da6bf8 in KApplication::shutDown() ()
   from /usr/kde3.3/lib/libkdecore.so.4
#14 0x40da6d9c in KApplication::qt_emit(int, QUObject*) ()
---Type <return> to continue, or q <return> to quit---
   from /usr/kde3.3/lib/libkdecore.so.4
#15 0x40e4b8e3 in KUniqueApplication::qt_emit(int, QUObject*) ()
   from /usr/kde3.3/lib/libkdecore.so.4
#16 0x41250404 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#17 0x412501c3 in QObject::activate_signal(int) ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#18 0x41555246 in QApplication::aboutToQuit() ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#19 0x41207b5f in QEventLoop::enterLoop() ()
   from /usr/kde3.3/lib/libqt-mt.so.3
#20 0x41207a14 in QEventLoop::exec() () from /usr/kde3.3/lib/libqt-mt.so.3
#21 0x411f6ce0 in QApplication::exec() () from /usr/kde3.3/lib/libqt-mt.so.3
#22 0x08083c5e in main ()
#23 0x41acfc57 in __libc_start_main () from /lib/i686/libc.so.6
Comment 9 Michael Pyne 2004-08-22 03:20:32 UTC
It seems to be crashing while trying to activate the "stop" action.  This should only happen if the PlayerManager instance was destructed though, which shouldn't happen by that time (actually I can't find a place where it does happen).  Odd.
Comment 10 prudek 2004-08-22 10:05:42 UTC
It crashes when a user invokes logout while the JuK window is opened. It does not crash when a user invokes logout while the JuK window is minimized.
Comment 11 Michael Pyne 2004-09-19 10:33:05 UTC
CVS commit by mpyne: 

Move some destructor code into the JuK class dtor.  Hopefully this will fix bug 87244, as it fixed the crash on my system.

Reporter:  If it doesn't fix the bug, feel free to reopen it.

CCMAIL:87244-done@bugs.kde.org


  M +4 -5      juk.cpp   1.223


--- kdemultimedia/juk/juk.cpp  #1.222:1.223
@@ -76,5 +76,8 @@ JuK::JuK(QWidget *parent, const char *na
 JuK::~JuK()
 {
-
+    action("stop")->activate();
+    delete m_systemTray;
+    m_systemTray = 0;
+    delete m_splitter;
 }
 
@@ -345,11 +348,7 @@ bool JuK::queryExit()
 
     hide();
-    action("stop")->activate();
-    delete m_systemTray;
-    m_systemTray = 0;
 
     Cache::instance()->save();
     saveConfig();
-    delete m_splitter;
     return true;
 }


Comment 12 Michael Pyne 2004-09-19 10:34:12 UTC
CVS commit by mpyne: 

Backport fix for bug 87244 to KDE 3.3.

CCMAIL:87244@bugs.kde.org


  M +4 -5      juk.cpp   1.214.2.3


--- kdemultimedia/juk/juk.cpp  #1.214.2.2:1.214.2.3
@@ -74,5 +74,8 @@ JuK::JuK(QWidget *parent, const char *na
 JuK::~JuK()
 {
-
+    action("stop")->activate();
+    delete m_systemTray;
+    m_systemTray = 0;
+    delete m_splitter;
 }
 
@@ -330,11 +333,7 @@ bool JuK::queryExit()
 
     hide();
-    action("stop")->activate();
-    delete m_systemTray;
-    m_systemTray = 0;
 
     Cache::instance()->save();
     saveConfig();
-    delete m_splitter;
     return true;
 }