Exception in AudioThumbnail destructor

Development
1

I’m getting an access violation exception thrown from CriticalSection::enter() in Visual Studio. This occurs systematically on Windows during app shutdown, when an AudioThumbnail is destroyed as part of a host object’s destruction. The same code has no problems on Mac. The call stack is:

juce::CriticalSection::enter() Line 46	C++
juce::GenericScopedLock<juce::CriticalSection>::GenericScopedLock<juce::CriticalSection>(const juce::CriticalSection & lock) Line 67	C++
juce::TimeSliceThread::removeTimeSliceClient(juce::TimeSliceClient * client) Line 49	C++
juce::AudioThumbnail::LevelDataSource::~LevelDataSource() Line 103	C++
[External Code]	
juce::AudioThumbnail::clear() Line 559	C++
juce::AudioThumbnail::~AudioThumbnail() Line 554	C++

I’ve set it up using a reader:

File file = parentDir.getChildFile (fileName);
			auto* reader = formatManager.createReaderFor (file);
			if (reader != nullptr) {
				thumbnail.setReader (reader, fileName.hashCode64());
			}

What could be the cause of this and how to prevent it? AFAIK no unusual threading is going on.

Maybe i should add that i have several components held in an OwnedArray. Each component has an AudioThumbnail. These thumbnails may reference the same audio file, but each makes it’s own reader for the thumbnail.

2

It’s worth double-checking the order of destruction of the AudioThumbnail and the AudioThumbnailCache. The Cache must stay alive for the entire time that the thumbnail is alive. From the stack trace, it looks like the crash happens while accessing the contents of the Cache, which suggests that the Cache has already been destroyed at this point.

1 Like
3

Yes, that’s it. The cache was after the owned array in the member list. Changing their order solves it. Clearing the array explicitly in the destructor seems to work also. Been a while since C++. Need to get into grips with all this stuff again. Thanks a million @reuk!

1 Like