Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old 01-04-2023, 11:10 AM   #1
reuk
Human being with feelings
 
Join Date: Jan 2021
Posts: 10
Default Segfault when destroying JUCE LV2 plug-in on macOS while editor is visible

I'm not sure whether this is a bug on JUCE's side, or in REAPER, but at the moment I'm leaning towards it being REAPER's problem.

To reproduce the issue, on macOS, load a JUCE LV2 plug-in on a new channel. Then, with the plug-in's editor open, right-click on the insert and select "Delete FX". REAPER will then crash.

On debugging this, it looks like the crash happens when cleaning up the autorelease pool after handling the mouse click event that causes the FX to be deleted. The stack trace usually goes through a few `NSView` members just before the crash, so I assume that the problem involves the FX editor. When I stick a breakpoint on `dlclose`, I notice that the DLL is unloaded before the autorelease pool is cleaned up. My theory at the moment is that the autorelease pool tries to call a `release` or `dealloc` implementation from the shared library, which fails because the library is no longer loaded.

Again, I'm not sure whether this is something that can be solved on JUCE's side, but I suspect not. At the moment, I can see that `autorelease` is being called on the JUCE NSView inside a stack trace like the following:

Code:
[AppKit] -[NSView _setSuperview:] 0x00007ff8164ba38a
[AppKit] -[NSView removeFromSuperview] 0x00007ff8164dec68
[REAPER] lv2_plugin::QuitConfig() 0x0000000104731cf5
[REAPER] FxDsp::~FxDsp() 0x00000001044c3e08
[REAPER] FxChain::removeDspFromChain(int, bool) 0x00000001044e4b94
[REAPER] MediaTrack::DoMixerFxMenu(HWND__*, POINT, int, int) 0x0000000104392ac6
[REAPER] DoFXParmClick(HWND__*, long, MediaTrack*, bool, bool, WDL_VWnd*) 0x00000001046dd591
[REAPER] MediaTrack::OnTrackPanelRightClick(HWND__*, int, int, int) 0x00000001043913f5
[REAPER] MCPDisplayProc(HWND__*, unsigned int, unsigned long, long) 0x00000001046ec6cf
[REAPER] DefWindowProc(HWND__*, unsigned int, unsigned long, long) 0x000000010465cbd3
[REAPER] MCPDisplayProc(HWND__*, unsigned int, unsigned long, long) 0x00000001046ec949
[REAPER] SWELL_SendMouseMessage(REAPERSwell_hwnd*, int, NSEvent*) 0x0000000104631f2c
[AppKit] -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] 0x00007ff8165ff654
[AppKit] -[NSWindow(NSEventRouting) sendEvent:] 0x00007ff8165fea6f
[AppKit] -[NSApplication(NSEvent) sendEvent:] 0x00007ff8165fcdde
[REAPER] -[REAPERapp sendEvent:] 0x0000000104476f9b
[AppKit] -[NSApplication _handleEvent:] 0x00007ff8168bb885
[AppKit] -[NSApplication run] 0x00007ff81648c41c
[AppKit] NSApplicationMain 0x00007ff816460427
[dyld] start 0x00007ff812f42310
I don't know exactly where the nearest enclosing autorelease pool would be at this point, but it seems to be the one in `[NSApplication run]`. Perhaps adding an autorelease pool around the `removeFromSuperview` call would allow any objects autoreleased by the system to be cleaned up before `dlclose` is called.

It would be great if someone could try this out and confirm the problem. Please let me know if you need any further details, or need a plugin for testing.
reuk is offline   Reply With Quote
 

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:54 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.