MythMusic crash on exit

[Nigel]

On Mac OS X, I have been getting this for many weeks:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
0x000f1fda in q_atomic_decrement (ptr=0x4) at /Volumes/MythBuild/.osx-packager/build/include/QtCore/qatomic_i386.h:102
102                      : "memory");
(gdb) where
#0  0x000f1fda in q_atomic_decrement (ptr=0x4) at /Volumes/MythBuild/.osx-packager/build/include/QtCore/qatomic_i386.h:102
#1  0x000f202b in QBasicAtomic::deref (this=0x4) at /Volumes/MythBuild/.osx-packager/build/include/QtCore/qatomic.h:98
#2  0x000f230d in QString::~QString (this=0x1a10b12c) at /Volumes/MythBuild/.osx-packager/build/include/QtCore/qstring.h:812
#3  0x1ee2e2ef in MetadataImp::~MetadataImp ()
#4  0x0490769b in Q3GList::clear ()
#5  0x1c5ca1e9 in Q3PtrList<Metadata>::clear (this=0x1a114b50) at /Volumes/MythBuild/.osx-packager/build/include/Qt3Support/q3ptrlist.h:103
#6  0x1c503b76 in AllMusic::~AllMusic (this=0x1a114b50) at metadata.cpp:900
#7  0x1c4ef254 in postMusic () at main.cpp:496

which could be either a QString thread issue, or memory corruption that I don't understand. I will try and narrow down an SVN range, but for now, commenting out m_all_music.setAutoDelete(true); is a workaround.
I'm actually wondering if the gMusicData could stay around between plugin invocations. For folk with large music libraries, it might mean faster entry after the first time into music?

[stuartm]

Nigel, on the subject of having gMusicData stay around, I'm thinking of loading it on startup so that we can use the music miniplayer at any time, without needing to enter mythmusic first.

Either way, I want to re-write the UI and playlist code in 0.23, so this should hopefully get resolved when that happens.

[Nigel]

I think the original bug was squashed about a month ago with some library build changes. mythfrontend now hangs waiting for the MediaMonitor? to Stop, but I will close this.
A background thread to populate gMusicData in mythplugin_init() (via runScan() ?) might be sensible, but not now.