illogic-al.Org

Today after my amarok bundle crashed (yet again), and I got the DrKonqui dialog which began using up 171% of my cpu making my fans go crazy, I remembered something. It was not always so. I remembered that I used to have to wait for the Apple Crash Reporter (ACR) to generate a backtrace (bt) before I could launch Amarok again. The ACR immediately generates a bt when OS X programs crash. This seems to take longer than DrKonqui because, with DrKonqui you could just quit and not generate a bt, which I would frequently do. And while I know it's not the right thing to do generating a bt is extremely annoying when I'm doing something which requires restarting amarok. Like say adding files to the bundle, quitting, then restarting to see that this didn't help at all with my kio problems. I was reminded today that not being allowed to dismiss the crash dialog before it generates its bt is probably a good thing though. I was trying to document how I came up with the following:

Index: ../src/ActionClasses.cpp
===================================================================
--- ../src/ActionClasses.cpp (revision 813638)
+++ ../src/ActionClasses.cpp (working copy)
@@ -467,7 +467,7 @@
setIcon( KIcon("media-playback-stop-amarok") );
setObjectName( "stop" );
setGlobalShortcut( KShortcut( Qt::META + Qt::Key_V ) );
- setMenu( Amarok::StopMenu::instance() );
+ //setMenu( Amarok::StopMenu::instance() );
connect( this, SIGNAL( triggered() ), The::engineController(), SLOT( stop() ) );
ac->addAction( "stop", this );
setEnabled( false ); // Disable action at startup

See commenting out that setMenu function allows amarok to quit normally, instead of crashing on exit. I seem to remember markey complaining about that once too. Anyway, now I have a piece of code and I can't rightly remember how it got there. I ditched the backtrace that led me here but I decided to see if I couldn't find it again...

orville@cube:am_build$ ll ../src/ActionClasses.cpp*
-rw-r--r-- 1 orville staff 19359 May 26 21:44 ../src/ActionClasses.cpp
-rw-r--r-- 1 orville staff 19364 May 21 11:24 ../src/ActionClasses.cpp~
So I messed w/ that file between May 21st and 26th. The 26th was probably the last time svn up touched the file. The ~ file was created by vim when I messed with it.

But I still need the backtrace right? Yup. Well OS X thankfully takes care of that by saving crash logs in ~/Library/Logs/CrashReporter/. In that directory you can find all the crash logs for that user's programs listed by name, date, pid and more. They never really meant much to me till I happened upon http://developer.apple.com/technotes/tn2004/tn2123.html . Yes, I browse the ADC for fun when I'm bored. Go die in a fire. Through the magic of browser tabs that never close and session recovery (TY Firefox 3!) I used the Amarok_2008-03-22-114749_orvilles-macbook-pro-15.crash file (close enough to May 21) to (finally) find what was causing the problem. This is what it told me

Process: Amarok [76944]
Path: Amarok
Identifier: Amarok
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: launchd [1]

Date/Time: 2008-03-22 11:47:49.708 -0400
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0

Thread 0 Crashed:
0 QtGui 0x0392dee3 QMenuPrivate::QMacMenuPrivate::~QMacMenuPrivate() + 419
1 QtGui 0x038c2ffd QMenuPrivate::~QMenuPrivate() + 93
2 QtCore 0x00335101 QObject::~QObject() + 1249
3 QtGui 0x03516df0 QWidget::~QWidget() + 464
4 libkdeui.5.dylib 0x01391757 KMenu::~KMenu() + 101 (kmenu.cpp:127)
5 libamaroklib.1.dylib 0x00b86084 Amarok::StopMenu::~StopMenu() + 56 (actionclasses.h:137)
6 libamaroklib.1.dylib 0x00b860b9 Amarok::StopMenu::~StopMenu() + 17 (actionclasses.h:137)
7 libamaroklib.1.dylib 0x00b84135 __tcf_2 + 27 (actionclasses.cpp:499)
8 libSystem.B.dylib 0x9461a53c __cxa_finalize + 241
9 libSystem.B.dylib 0x9461a430 exit + 33
10 0x0000f713 start + 63

So this is what I did
//setMenu( Amarok::StopMenu::instance() );

And lookit that, problem solved. Temporarily. If I had to guess I'd say the dtor is taking a wrong detour somewhere. :-D Anyhoo, save the guy for later. Per'aps dtrace and gdb will help me fix it when I'm not so lazy and actually understand what the code is trying to do. Or maybe I'll just passively inform markey that maybe I've stumbled onto to source of his problem. Yeah, I like that idea. Hope I remember that after my shower...