MacOS - non-Catalina hang crash when using more than one OpenGL context

General JUCE discussion
1

Hi, I’ve got a hang crash on OpenGL when I use more than one openGLContext.
I think it gets stuck in a loop on swapbuffers. Here’s the debugger after I hit pause when it starts to hang. Using AU.

Screen Shot 2020-02-15 at 22.13.19
Screen Shot 2020-02-15 at 22.13.191920×1080 661 KB

I don’t understand what I’m looking at here, deep in a openGL context mutex wait, or something?

If I delete all the contexts and just have one then it renders perfectly, no matter which one it is.
This hang happens with Master and Develop unfortunately.
It used to work fine until I got the Juce code, to update it. I don’t know which version worked, sorry. I keep up to date quite a lot - more fool me, I guess.
Customers reporting problems have El Capitan. But it also breaks on my old iMac, which is driving me a bit nuts as I have to drag out an old High Sierra Mac from storage, and Apple has made it run incredibly slowly for some Apple reason. The whole plug-in runs fine in Catalina, smooth as heck. But I’m getting some complaints from irate customers, and that won’t do, because it’s not long before they’ll want a refund…

2

I’d first try the following to narrow down the problem:

  1. you can pretty much git-bisect JUCE to see the culprit quickly. (I guess).
  2. I guess in the screenshot you’re using Xcode 9 or last Xcode running on 10.13? so you can narrow the macOS SDK.
  3. is this your opengl code or you’re just using JUCE renderer under OpenGL?
  4. check other threads which might shed some light of course.
1 Like
3

Thanks for replying.

  1. It’s going to take some serious back tracking of all of Juce’s bug fixes, but yeah.
  2. Yes, I was compiling with the latest Xcode and targeting 10.8 when this was noticed first. SDK version doesn’t seem to matter.
  3. I’m using Juce’s openGLcontext as part of a component, like the demos show.
  4. Good idea, but to get the renderer to work, all I had to do was only have one context, like I mentioned.

Last night I found a forum thread on here that mentions I should only have one context anyway. Plus I remember reading somewhere whilst learning OpenGl years ago, that OpenGL should never be on a thread. It’s just strange that it worked for me all this time. It’s really useful having multiple contexts.

1 Like
4

I’ve tried SDK 10.11, 10.12, 10.13. They all hang the system, whatever target i use. I wonder if it’s the latest changes to Juce’s renderer that’s caused this. I shall see tomorrow, but it looks like I’ll have to bite the bullet and reorganise my components to render from the same context, which is a pain, but I guess it will work as long as the correct viewport position is selected… I don’t know yet.

5

I’ve found the commit that starts the multiple context problem for me.
It was b8c9ac3 on the 5th of November that breaks my plug-in rendering.
4048af5 on the 4th works well.
So Windows: Restored MinGW compatibility breaks it. I haven’t looked any further as I’m now exhausted.
Does it give any Jucers any clues please?
Thanks,
Dave H

6

I can’t find commits with these hashes in GitHub - juce-framework/JUCE: JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.. Are there specific to your own fork?

Windows: Restored MinGW compatibility touched 2 files that are only compiled on Windows (they have win32 in their name). I don’t see how that could have an impact on macOS.

1 Like
7

Sorry, it was a typo, I meant b7c8ac3, and 4048a5f

I know, it’s very odd,
the only thing I can think of is a memory leak, that only happens with a certain build, it’s odd to only happens on everything AFTER that specific date though.

I’ve gone through all my memory allocations today, there was nothing I could see causing this problem.

8

The only way I got this to work with the latest code was to only have one OpenGL context in ‘PluginEditor’ And render the 3 child components by hand from there!
It is not ideal as I had to make holes in the background for the GL to show through. Not a big problem for me as most of the panels are supposed to be background screens anyway.
Thanks,
Dave H.