OwlPlug crashed while validating Arturia Stage 73- plugin #105
Comments
|
Hi @DavidJameson ! Thank you for reporting this issue. First of all, to avoid frustrating crashes while we find the root cause, you can disable the native discovery for this specific plugin. You can disable native discovery for a plugin by searching it on OwlPlug Plugins tab. If you have a doubt about which plugin causing the issue you can restart a sync. After a crash during sync, a crash-report screen should be displayed if you restart OwlPlug. You can disable Native discovery for the last analyzed plugin at this time.
open /Applications/OwlPlug.app |
I mentioned above that I'm one of the developers of Gig Performer, which is a plugin host designed specifically for live performance (as opposed to recording) --- trust me, we're deeply aware of the problem where some hosts (and we are one of them) exercise plugins far more deeply than most DAWs. I mentioned (and posted an image) of Gig Performer properly validating all versions of that plugin (VST, VST3 and AU).
I don't know -- OwlPlug crashed on that VST and frankly I didn't bother going any further. But here is some more info:
A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x000000017a3e25d6, pid=6721, tid=259 JRE version: OpenJDK Runtime Environment AdoptOpenJDK (14.0.2+12) (build 14.0.2+12) No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again An error report file with more information is saved as: If you would like to submit a bug report, please visit: Abort trap: 6
dhj-> validatevst3 /Library/Audio/Plug-Ins/VST3/Stage-73\ V2.vst3
(Edited to get rid of stupid markdown) |
|
Thank you for these precisions and extra logs.
Java illegal access at startup is a known issue on an OwlPlug dependency. It may be fixed soon. There is no impact on plugin scans. It happens because of illegal use of reflection API between some UI components and UI engine.
There is something really strange... I'm not sure it's the VST3 version that is crashing, for me, it's the VST2 but the version displayed in the OwlPlug screenshot is wrong. From my point of view, In your plugin setup:
Do you have a similar validator tool for vst, and run something like this: validatevst /Library/Audio/Plug-Ins/VST/Stage-73\ V2.vst |
|
Sorry, just saw this now. Yes, our validator can handle VST2, VST3 and AU. See below (again, I have to post an image as the XML is being erroneously removed
|
|
is a VST/VST2 but it can't be natively scanned by OwlPlug. Why not? |
I don't know, it's the problem we are trying to solve. 😉 Which JUCE version are you using to validate plugins (or at least the version used by GigPerformer) ? |
|
We started with JUCE 4 (bought a commercial license and upgraded over time). That said, we found JUCE to have some very obscure bugs all over the place (some of which they still haven't fixed) and so we ended up just incorporating our own fixes all over the place over time. Unfortunately, I don't remember any more whether we had to do any fixes to the scanner - that would have been almost 5 years ago now but I wouldn't be surprised if we had to tweak the underlying scanner code at the time. But looking again at that original stacktrace, I'm wondering if the problem is something funky between the VST2 and Java. Have you tried writing a simple scanner with JUCE in C++ or even just try running the basic sample plugin host that comes with JUCE to see if that scans properly? |
|
Hi @DavidJameson , I reproduced the issue on a MacOs Catalina with the OwlPlug latest version (0.17.1) and the demo version of ArturiaStage V2. I've updated OwlPlug view to track unstable plugins more easily. After some tests, the plugin behavior during sync seems unpredictable. Sometimes, VST2 and VST3 are synced correctly without any crash.
Sometimes, only the VST2 plugin crashes during sync.
Sometimes, only the VST3 plugin crashes during sync.
Something wrong is happening on the plugin side and the JVM can't recover. It's the same issue for both VST2 and VST3 formats. For now, I don't know why it crashes. Sometimes, plugin DRMs are responsible for undesirable side effects. I have a plugin scanner somewhere made using Juce, I can try to reproduce without the Java layer. |
|
Well, I think it will be critical to check without Java. I would note that those Arturia plugins are in use with pretty much every DAW and live plugin host in existence so I'm struggling to buy into the notion that something is wrong on the plugin side. |
|
|
Hello @DavidJameson; A "sandbox scanner" has been added in OwlPlug 1.19.0. A selector is available in the Options tab to choose between two implementations OwlPlug JNI (legacy) and the new OwlPlug Scanner. For now, the legacy implementation is used by default, but based on community feedback, it may be replaced by the new scanner in future releases (#138). More information about this feature is available on this wiki page. For now, I still can't understand why the sync fails half the time on Arturia Stage using OwlPlug JNI (legacy). Can you try to sync your plugins collection with Native Discovery set on OwlPlug Scanner ? It should be more stable 🤞 |
|
Downloaded it, cleared cache, etc - tried to sync and it crashed (it was set to use the new Scanner)
Relevant stack trace below
On Mar 13, 2022, at 6:03 AM, Arthur Poiret ***@***.***> wrote:
Hello @DavidJameson <https://github.com/DavidJameson>;
A "sandbox scanner" has been added in OwlPlug 1.19.0 <https://github.com/DropSnorz/OwlPlug/releases/tag/1.19.0>. A selector is available in the Options tab to choose between two implementations OwlPlug JNI (legacy) and the new OwlPlug Scanner. For now, the legacy implementation is used by default, but based on community feedback, it may be replaced by the new scanner in future releases (#138 <#138>).
More information about this feature is available on this wiki page <https://github.com/DropSnorz/OwlPlug/wiki/Synchronize-plugins>.
For now, I still can't understand why the sync fails half the time on Arturia Stage using OwlPlug JNI (legacy).
But I've successfully scanned the Arturia Stage vst2 and vst3 on MacOS without any crashes using OwlPlug Scanner. One time I've faced a timeout (10s without result) during the vst2 sync, but I never reproduced it.
Can you try to sync your plugins collection with Native Discovery set on OwlPlug Scanner ? It should be more stable 🤞
—
Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNSSU6AQ4XLEVZCASO4HE3U7W4O7ANCNFSM5CSGZNMQ>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.
Translated Report (Full Report Below)
-------------------------------------
Process: OwlPlug [87432]
Path: /Applications/OwlPlug.app/Contents/MacOS/OwlPlug
Identifier: owlplug
Version: 1.19.0 (1.19.0)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-03-13 07:37:53.3907 -0400
OS Version: macOS 12.2.1 (21D62)
Report Version: 12
Bridge OS Version: 6.2 (19P744)
Anonymous UUID: 04F4458F-DB6A-A71F-1010-0139842E5925
Time Awake Since Boot: 560000 seconds
System Integrity Protection: disabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
VM Region Info: 0 is not in any region. Bytes before following region: 4322267136
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 101a09000-101a1f000 [ 88K] r-x/rwx SM=COW ...MacOS/OwlPlug
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7ff81a49e112 __pthread_kill + 10
1 libsystem_pthread.dylib 0x7ff81a4d4214 pthread_kill + 263
2 libsystem_c.dylib 0x7ff81a420d10 abort + 123
3 libjvm.dylib 0x103582601 os::abort(bool, void*, void const*) + 49
4 libjvm.dylib 0x1037e76c8 VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) + 2968
5 libjvm.dylib 0x1037e6afc VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) + 156
6 libjvm.dylib 0x1037e7771 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) + 33
7 libjvm.dylib 0x1036aee0b JVM_handle_bsd_signal + 363
8 libsystem_platform.dylib 0x7ff81a4e9e2d _sigtramp + 29
9 ??? 0x4084c00000000000 ???
10 Stage-73 V2 0x165f94261 0x164d28000 + 19317345
11 Stage-73 V2 0x165da2067 0x164d28000 + 17277031
12 Stage-73 V2 0x165da27c7 0x164d28000 + 17278919
13 CoreFoundation 0x7ff81a59b8fd __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
14 CoreFoundation 0x7ff81a59b865 __CFRunLoopDoSource0 + 180
15 CoreFoundation 0x7ff81a59b5e4 __CFRunLoopDoSources0 + 242
16 CoreFoundation 0x7ff81a59a01b __CFRunLoopRun + 893
17 CoreFoundation 0x7ff81a5995dd CFRunLoopRunSpecific + 563
18 HIToolbox 0x7ff8231d64f1 RunCurrentEventLoopInMode + 292
19 HIToolbox 0x7ff8231d6247 ReceiveNextEventCommon + 587
20 HIToolbox 0x7ff8231d5fe5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
21 AppKit 0x7ff81cfc8d88 _DPSNextEvent + 886
22 AppKit 0x7ff81cfc73f4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1411
23 AppKit 0x7ff81cfb9919 -[NSApplication run] + 586
24 libglass.dylib 0x10290a2a5 -[GlassApplication runLoop:] + 1941
25 Foundation 0x7ff81b421b03 __NSThreadPerformPerform + 179
26 CoreFoundation 0x7ff81a59b8fd __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
27 CoreFoundation 0x7ff81a59b865 __CFRunLoopDoSource0 + 180
28 CoreFoundation 0x7ff81a59b5e4 __CFRunLoopDoSources0 + 242
29 CoreFoundation 0x7ff81a59a01b __CFRunLoopRun + 893
30 CoreFoundation 0x7ff81a5995dd CFRunLoopRunSpecific + 563
31 libjli.dylib 0x101b93e82 CreateExecutionEnvironment + 402
32 libjli.dylib 0x101b8f6a8 JLI_Launch + 1496
33 OwlPlug 0x101a16ffe jvmLauncherStartJvm + 142
34 OwlPlug 0x101a15945 Jvm::launch() + 885
35 OwlPlug 0x101a18828 (anonymous namespace)::initJvmLauncher() + 1224
36 OwlPlug 0x101a1b021 app::launch(std::nothrow_t const&, void (*)(), LogAppender*) + 257
37 dyld 0x10933c4fe start + 462
|
|
Thank you so much for testing! Arggg, this is so strange, how the JVM can crash... Seems the legacy scanner is still used 🤔 Can you send me the content of the app logs located in: Thank you, |
|
Unfortunately, still seeing all sorts of issues.
Clearing caches and user data does NOT appear to reset the scanner — at least it still displays OwlPlug Scanner afterwards.
Just for grins, I cleared everything and even removed the .owlplug folder.
When I ran it again it saw me as a new user, as I would expect. However, In this case, it did not give me the option to select a scanner, it just started running and then crashed the same way as earlier.
That button marked “Ignore step” should be called “Cancel"
I finally managed to get it to run as a “new” user and it scanned a few plugins (seemed to get past the Stage 73) but then failed a few seconds later with the following message. There’s absolutely no way it could have scanned all my plugins in a few seconds.
Also, I have no idea what to do with the message “Check your plugin directory” — what exactly is one supposed to check?
I took a look at the log (attached below) and I see that you’re timing out after 10 seconds — that will absolutely not be enough time — from experience we know that we have to use a timeout of at least 2 minutes, specially for plugins that need to “phone home"
The plugin that it was testing (Korg Kronos) was sending messages out on every port on my system and on every MIDI channel of each port, looking for a Kronos (which is not in fact connected to this computer) and that process took about 30 seconds.
… On Mar 13, 2022, at 8:05 AM, Arthur Poiret ***@***.***> wrote:
Thank you so much for testing!
Arggg, this is so strange, how the JVM can crash... Seems the legacy scanner is still used 🤔
Clearing all caches and user data in Options will reset the scanner used, so the new scanner must be defined after a hit to "Clear user data".
Can you send me the content of the app logs located in:
~/home/{you}/.owlplug/logs/owlplug.log
Thank you,
—
Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNSSU5UUTWWA6HSSIGPROTU7XKXNANCNFSM5CSGZNMQ>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.
|
|
Thank you @DavidJameson, Clearing user data reset the scanner after a reboot. The "preferred" scanner is selected after the application start. I can't find attached logs. As you answered by e-mail, Github seems to ignore the attached files. I agree, the error message you faced is not clear enough. The log will be more detailed. Thank you for your feedback about the timeout. I may increase it to something like 20 or 30 seconds by default. If a plugin analysis reaches the timeout it will be skipped but the plugin will appear in the list anyway. Maybe I should add an option to increase or decrease this read timeout. |
|
20-30 seconds is simply not long enough…we have come across plugins that take way longer than that, though no idea why. That said, you just need enough to know the version.
David
-----------------
Dr. David H Jameson
Co-founder, Deskew Technologies, LLC
https://gigperformer.com
Own The Stage™️
… On Mar 20, 2022, at 4:23 PM, Arthur Poiret ***@***.***> wrote:
Thank you @DavidJameson,
Clearing user data reset the scanner after a reboot. The "preferred" scanner is selected after the application start.
I've opened issue #140 to correctly reflect changes in UI and mention that the app should be restated to truly reset everything.
I can't find attached logs. As you answered by e-mail, Github seems to ignore the attached files.
I agree, the error message you faced is not clear enough. The log will be more detailed.
Thank you for your feedback about the timeout. I may increase it to something like 20 or 30 seconds by default. If a plugin analysis reaches the timeout it will be skipped but the plugin will appear in the list anyway. Maybe I should add an option to increase or decrease this read timeout.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.
|
Process: OwlPlug [89688]
Path: /Applications/OwlPlug.app/Contents/MacOS/OwlPlug
Identifier: owlplug
Version: 0.17.0 (100)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: OwlPlug [89688]
User ID: 501
Date/Time: 2021-08-21 17:03:23.232 -0400
OS Version: macOS 11.5.1 (20G80)
Report Version: 12
Bridge OS Version: 5.5 (18P4759a)
Anonymous UUID: 04F4458F-DB6A-A71F-1010-0139842E5925
Time Awake Since Boot: 2100000 seconds
Thought I'd give this tool a shot (it's a great idea, long overdue) but unfortunately it crashed rather quickly. See the appropriate section of the stack trace below for Mac OS.
While I understand that this looks like an Arturia crash, the fact is that that plugin validates just fine in other hosts, including our own (Gig Performer) which is also JUCE based.
Just to be sure, I just revalidated them with our system (see attached screenshot) with no issues.
System Integrity Protection: disabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0:
-->
__TEXT 106fb5000-106fb6000 [ 4K] r-x/rwx SM=COW /Applications/OwlPlug.app/Contents/MacOS/OwlPlug
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff2033292e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff203615bd pthread_kill + 263
2 libsystem_c.dylib 0x00007fff202b6406 abort + 125
3 libjvm.dylib 0x0000000107685cc2 os::abort(bool, void*, void const*) + 22
4 libjvm.dylib 0x0000000107834e2c VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) + 2780
5 libjvm.dylib 0x000000010783432b VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) + 155
6 libjvm.dylib 0x0000000107834eb3 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) + 33
7 libjvm.dylib 0x00000001076895b5 JVM_handle_bsd_signal + 792
8 libjvm.dylib 0x00000001076871ac signalHandler(int, __siginfo*, void*) + 45
9 libsystem_platform.dylib 0x00007fff203a6d7d _sigtramp + 29
10 ??? 0x0000000113a461dc 0 + 4624507356
11 com.Arturia.Stage-73-V2.vst 0x000000016881a261 0x1675ae000 + 19317345
12 com.Arturia.Stage-73-V2.vst 0x0000000168628067 0x1675ae000 + 17277031
13 com.Arturia.Stage-73-V2.vst 0x00000001686287c7 0x1675ae000 + 17278919
14 com.apple.CoreFoundation 0x00007fff2045a94c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 17
15 com.apple.CoreFoundation 0x00007fff2045a8b4 __CFRunLoopDoSource0 + 180
16 com.apple.CoreFoundation 0x00007fff2045a634 __CFRunLoopDoSources0 + 242
17 com.apple.CoreFoundation 0x00007fff2045905c __CFRunLoopRun + 893
18 com.apple.CoreFoundation 0x00007fff2045861c CFRunLoopRunSpecific + 563
19 com.apple.HIToolbox 0x00007fff2869da83 RunCurrentEventLoopInMode + 292
20 com.apple.HIToolbox 0x00007fff2869d7e5 ReceiveNextEventCommon + 587
21 com.apple.HIToolbox 0x00007fff2869d583 _BlockUntilNextEventMatchingListInModeWithFilter + 70
22 com.apple.AppKit 0x00007fff22c5f502 _DPSNextEvent + 864
23 com.apple.AppKit 0x00007fff22c5dcd5 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1364
24 com.apple.AppKit 0x00007fff22c50049 -[NSApplication run] + 586
25 libglass.dylib 0x000000010b93623c -[GlassApplication runLoop:] + 1932
26 com.apple.Foundation 0x00007fff21208b81 __NSThreadPerformPerform + 204
27 com.apple.CoreFoundation 0x00007fff2045a94c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 17
28 com.apple.CoreFoundation 0x00007fff2045a8b4 __CFRunLoopDoSource0 + 180
29 com.apple.CoreFoundation 0x00007fff2045a634 __CFRunLoopDoSources0 + 242
30 com.apple.CoreFoundation 0x00007fff2045905c __CFRunLoopRun + 893
31 com.apple.CoreFoundation 0x00007fff2045861c CFRunLoopRunSpecific + 563
32 libjli.dylib 0x0000000107080615 CreateExecutionEnvironment + 398
33 libjli.dylib 0x000000010707c847 JLI_Launch + 1359
34 libapplauncher.dylib 0x000000010700c6e0 JavaLibrary::JavaVMCreate(unsigned long, char**) + 168
35 libapplauncher.dylib 0x000000010700bab9 JavaVirtualMachine::launchVM(JavaOptions&, std::__1::list<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >&) + 437
36 libapplauncher.dylib 0x000000010700a5b8 JavaVirtualMachine::StartJVM() + 1916
37 libapplauncher.dylib 0x0000000107009daf RunVM() + 31
38 libapplauncher.dylib 0x000000010701b41f start_launcher + 1247
39 owlplug 0x0000000106fb5cce main + 238
40 libdyld.dylib 0x00007fff2037cf3d start + 1
The text was updated successfully, but these errors were encountered: