Yes, I’ve investigated a little further and found that the crash under Mac (both PowerPC and Intel, as I’ve tested in the mean time) seems due to the specific repainting strategy implemented for the Mac platform.
As far as I could see looking at juce_RTASWrapper.cpp, editor repainting under Mac is periodically triggered by its specific Timer (forcedRepaintTimer) instance.
I think it to be the cause of the problem because this is the (top) of the resulting report when i try to load the demo into ProTools
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4
Command: Pro Tools LE
Path: ./Pro Tools LE
Parent: bash [10760]
Version: 7.3 (7.3f117)
PID: 10858
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000008
Thread 0 Crashed:
0 ...awmaterialsoftware.JuceDemo 0x111b9f24 juce::Timer::stopTimer() + 70 (juce_Timer.cpp:382)
1 ...awmaterialsoftware.JuceDemo 0x112b7597 JucePlugInProcess::JuceCustomUIView::EditorCompWrapper::paint(juce::Graphics&) + 23 (juce_RTASWrapper.cpp:368)
2 ...awmaterialsoftware.JuceDemo 0x11192979 juce::Component::paintEntireComponent(juce::Graphics&) + 1047 (juce_Component.cpp:1748)
3 ...awmaterialsoftware.JuceDemo 0x11211110 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 52 (juce_ComponentPeer.cpp:388)
4 ...awmaterialsoftware.JuceDemo 0x112ce7a7 juce::HIViewComponentPeer::RepaintManager::paint(CGContext*, int, int, int, int) + 1179 (juce_mac_Windowing.cpp:921)
5 ...awmaterialsoftware.JuceDemo 0x112cf125 juce::HIViewComponentPeer::hiViewDraw(OpaqueEventRef*) + 821 (juce_mac_Windowing.cpp:1478)
6 ...awmaterialsoftware.JuceDemo 0x112cf87f juce::HIViewComponentPeer::hiViewEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 595 (juce_mac_Windowing.cpp:1613)
7 com.apple.HIToolbox 0x92dd6537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
...
...
...
To better see what actually happens within stopTimer(), I added some DBG
statements into the function body:
DBG("In");
if (periodMs > 0)
{
DBG("InIf");
InternalTimerThread::remove (this);
periodMs = 0;
DBG("OutIf");
}
DBG("Out");
Loading this modified version produces the following on standard output:
JUCE v1.44
In
Out
Debugger() was called!
In
Bus error
This looks quite weird to me, because it shows that a first invocation of the stopTimer method resulted in bypassing the if body because of false condition (“In” and “Out” printed with no “InIf” and “OutIf”), while the second invocation entered the method but crashed before returning AND before entering the if body as well (no “Out” neither “InIf” printed).
Sounds strange, but the access to “periodMs” within the if condition somehow seems the only possible cause of crash. Suggestions on how to solve the problem?
P.S. maybe this topic needs to be renamed since it’s not dealing with Win32 issues only any longer…