EXC_BAD_ACCESS in message thread

General JUCE discussion
1

Hi there,

I’m a bit rusty on the C++ dev front, so apologies if I’ve got things wrong.

I’m working on an app that makes heavy use of a MIDI control surface, with all visual components also being controlled through the MIDI unit. I keep getting spurious BAD_ACCESS and I’ve not been able to trace down the cause. They seem to happen when there are several things happening at the same time, for example when turning two knobs on the MIDI unit simultaneously. Obviously this is something that would never happen in a mouse-controlled application.

The way I coordinate GUI, system and MIDI updates is through a Control, which creates a MessageManagerLock before calling any modifiers on their GUI component:

void Control::updateValue(int newValue){
  if(value != newValue){
    value = newValue;
    eventrouter->send(type, command, value);
    if(component != NULL){
      // lock the gui message thread
      const MessageManagerLock mmLock;
      component->setValue(value);
    }
  }
}

What I find on the stack when the application bugs out is generally something like this:

#0 0x900749e6 in mach_msg_trap
#1 0x9007c1dc in mach_msg
#2 0x95b600de in CFRunLoopRunSpecific
#3 0x95b60d18 in CFRunLoopRunInMode
#4 0x926586a0 in RunCurrentEventLoopInMode
#5 0x926584b9 in ReceiveNextEventCommon
#6 0x9279bd1f in ReceiveNextEvent
#7 0x00027095 in juce::juce_dispatchNextMessageOnSystemQueue at juce_mac_Windowing.cpp:2065
#8 0x000346dd in juce::MessageManager::dispatchNextMessage at juce_MessageManager.cpp:150
#9 0x00034a18 in juce::MessageManager::runDispatchLoop at juce_MessageManager.cpp:194
#10 0x00031faa in juce::JUCEApplication::main at juce_Application.cpp:206
#11 0x000321dd in juce::JUCEApplication::main at juce_Application.cpp:289
#12 0x000027f3 in main at Main.cpp:303

and

#0 0x95b62296 in CFGetTypeID
#1 0x93a2f081 in CGSUnionRegion
#2 0x93586fc5 in CreateUnion
#3 0x9358a656 in HIShapeCreateUnion
#4 0x926514ac in HIView::Invalidate
#5 0x926b9685 in HIViewSetNeedsDisplayInRect
#6 0x0002b358 in juce::HIViewComponentPeer::repaint at juce_mac_Windowing.cpp:760
#7 0x000585db in juce::Component::internalRepaint at juce_Component.cpp:1670
#8 0x0005858a in juce::Component::internalRepaint at juce_Component.cpp:1663
#9 0x0005858a in juce::Component::internalRepaint at juce_Component.cpp:1663
#10 0x0005858a in juce::Component::internalRepaint at juce_Component.cpp:1663
#11 0x000582ef in juce::Component::repaint at juce_Component.cpp:1626
#12 0x00058354 in juce::Component::repaint at juce_Component.cpp:1617
#13 0x00037b07 in juce::Button::setState at juce_Button.cpp:246
#14 0x000173af in CustomButtonComponent::setValue at CustomButtonComponent.cpp:154
#15 0x00012aa4 in Control::updateValue at Control.cpp:64
#16 0x0001e75d in StepCounter::getNextStepIndex at StepCounter.cpp:15
#17 0x0001b214 in StepSequencer::getNextStep at StepSequencer.cpp:66
#18 0x0001e585 in SequencerPlayer::handleIncomingMidiMessage at SequencerPlayer.cpp:33

Sometimes there’ll be another thread waiting for the MessageManagerLock.

So basically I’m at a loss - I can’t think of any other reason for things to crap out than a thread problem, and I can’t find what the thread problem is.

Any hints as to how I can track the problem down will be much appreciated!

The one thing I’ve noticed is that the MessageManager::runDispatchLoop() doesn’t seem to aquire a lock, I take it this is by design?

thanks in advance,

/m

2

So I thought I’d try to compile and debug the program on Windows XP to see if I can get a different view on the problem.
What I’ve found so far is the following, compiling Juce with CodeBlocks:

  • The method tween() in juce_PixelFormats needs to have forceinline removed to compile.
  • The files juce_FileInputSource.cpp and .h have to be added to the project.
  • I think there was a file missing in libFLAC too, and alloc.h failed because of a missing SIZE_T_MAX, but I disabled flac instead of getting it working. I can try again if prompted.

And… that’s it for now. I’ll see what debugging on windows gives (I don’t like the platfom much though, maybe I’ll try on linux instead!)

/m

3

Same problem here! Something must be fishy in the Mac MIDI code? I don’t know. But I can reproduce the problem on my Intel Mac, and I have only found out 5 minutes ago that all the EXC_BAD_ACCESS I had were related to this MIDI bug.

4

That’s a weird one.

But for a start, you should definitely avoid doing anything like that in your midi callback. It’s really a big no-no to lock the messagemanager or use any UI calls, because they could block for seconds.

Still strange that it’s crashing though. I guess it could be that some of those calls to the OS’s graphics library can’t deal with multithreading?

5

Yes, I called (by mistake) repaint() in the MIDI In Handler. Ofcourse not a good idea.