I was debugging a plugin on my MacBook when I decided to connect an external monitor and I got a crash on ~HeapBlock()
This is what I use to get the scale
auto dis = Desktop::getInstance().getDisplays().getPrimaryDisplay();
if (dis != nullptr) scale = dis->scale;
If I detach the monitor instead, it doesn’t crash.
you may want to check MessageManager::getInstance()->currentThreadHasLockedMessageManager()
and only use it in that case or otherwise use a local cache that was initialised the last time it worked
I can’t reproduce this with the AudioPluginDemo/AudioPluginHost.
Please could you provide more details about your setup, so that I can try to reproduce the issue?
For example, which operating system, plugin format, and plugin host are you using for testing? Do you encounter the same problem with any of the JUCE demo plugins?
Thanks but I have no idea where to use it. The code I use to get the scale is in the construction of the Editor, and then I store it to avoid recalling getPrimaryDisplay().
MacBook Pro 15" 2018, macOS Catalina 10.15.7. I’ve only tested Logic Pro 10.6.1, so AudioUnit.
I have not tested the demo plugins, I’ll try in the following days.
I’m using an HDMI cable attached to a USC-C hub to connect the external monitor.
Thanks. Does it happen every time you connect a display, or intermittently?
I’m unable to reproduce the issue with the AudioPluginDemo or DSPModulePluginDemo in Logic 10.6.1 on Catalina 10.15.7. I’ve tried plugging/unplugging the HDMI cable into a USB-C adapter, and also plugging/unplugging the adapter itself. To dig into this further, it would be helpful if you could provide a minimal project which reproduces the issue.
I’ve tried the demo project on two systems (16-inch macbook running Catalina, and a 15-inch macbook running Big Sur). In both cases, I opened the plugin in Logic 10.6.1, ensured the editor was visible, and then plugged/unplugged an external display a few times. I didn’t encounter any crashes. Perhaps the issue is only triggered by very specific hardware combinations.
Could you check whether the issue is also present when hosting in the AudioPluginHost? If it is, I’d recommend building both the AudioPluginHost and the DisplayTest plugin with Address Sanitizer enabled, and then triggering a crash. The full Address Sanitizer output should provide sufficient detail for me to identify the problem.
Ok, I think there’s something else going on here.
Running a few of my regular plugins built with develop tip, with pluginval, resulted in the same crash on HeapBlock.
edit (it was the other way around of course): I’m using OpenGL, if it’s enabled, it crashes, otherwise runs fine. It never crashes using a DAW unless I plug in the external monitor. But it crashes when I run it in pluginval.
The commit that’s causing this for me is this one: Removed Displays const_casts from ComponentPeer implementations · juce-framework/JUCE@fd83e0f · GitHub
I wasn’t able to replicate it with AudioPluginDemo though, I’ll dig deeper when I find the time.
I just had a related crash, with the master tip and a vst running in reaper.
I haven’t tried to reproduce yet, but it just happened after I woke up my mbp (I had put it to sleep while the plugin was running in reaper).
I’ll try to reproduce in the upcoming days and let you know if I can.
Glad I’m not alone in this! Are you using OpenGL?
You can try pluginval it almost always crashes if I have OpenGL enabled.
no, I’m not using opengl
I’ve not been able to get a consistent reproducible crash with this, but the following changes seem to fix the issue -
Can you see if you are still running into problems with this commit?
I’m getting reports of a very similar issue triggered when our plugin editor is open while the computer is waking from sleep. This is from a user using macOS 10.15, a mbp, and a Samsung T240HD monitor with a mini displayport to DVI-D cable. It happens intermittently, but has happened a handful of times. The crash report indicates that this is the same issue. He was using a build of ours against this commit.
