search

DropSnorz / OwlPlug

Audio plugin manager. Small tool to manage VST / AU / LV2 plugins on Windows, MacOS and Linux.
https://owlplug.com
GNU General Public License v3.0
287 stars 11 forks source link

OwlPlug crashed while validating Arturia Stage 73- plugin #105

Open DavidJameson opened 3 years ago

DavidJameson commented 3 years ago

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.

screenshot_5192

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

DropSnorz commented 3 years ago

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
DavidJameson commented 3 years ago

OwlPlug sync may go deeper than some daw during a regular scan. Most of the time, crashes are caused by a defective plugin or DRM interferences. Can you scan, load, and use the plugin in a daw without any problem ?

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).

You have several plugin formats (VST, VST3, AU) and versions installed. Which one is causing the crash ? It seems to be the .vst. Do other formats are synced correctly in OwlPlug ?

I don't know -- OwlPlug crashed on that VST and frankly I didn't bother going any further. But here is some more info:

1) When I ran from a terminal Window, I saw an illegal access from Java 3956 INFO com.owlplug.host.util.LibraryLoader - Library /var/folders/n2/9h010cts31sc8_n4yd1z__kh0000gn/T//owlplug-host-0.2.0.dylib successfully loaded 4373 INFO c.o.c.components.ApplicationMonitor - Application monitor started 4373 INFO c.o.c.components.ApplicationMonitor - Previous application instance not terminated safely 4498 INFO o.s.boot.SpringApplication - Started application in 4.246 seconds (JVM running for 6.019) WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.jfoenix.adapters.ReflectionHelper (jar:file:/Applications/OwlPlug.app/Contents/app/owlplug.jar!/BOOT-INF/lib/jfoenix-9.0.10.jar!/) to method java.lang.reflect.AccessibleObject.setAccessible0(boolean) WARNING: Please consider reporting this to the maintainers of com.jfoenix.adapters.ReflectionHelper WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release

2) Check the attached image where you identify (correctly) the plugin version of the Stage-73 but you don't seem to know who is the manufacturer nor the category. Gig Performer (see image in my original post) correctly identifies both.

screenshot_5193

3) I tried again to validate that plugin (via running through the command line) and saw the following error from the terminal.

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) Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (14.0.2+12, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) Problematic frame: C [Stage-73 V2+0x5fc5d6] GetPluginFactory+0x589a6

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: /var/folders/n2/9h010cts31sc8_n4yd1z__kh0000gn/T//hs_err_pid6721.log

If you would like to submit a bug report, please visit: https://github.com/AdoptOpenJDK/openjdk-support/issues The crash happened outside the Java Virtual Machine in native code. See problematic frame for where to report the bug.

Abort trap: 6 [/Application

4) If I use our own scanner from the command line on that VST (by the way, it's the VST3 version that is failing with OwlPlug) I correctly retrieve all the info

dhj-> validatevst3 /Library/Audio/Plug-Ins/VST3/Stage-73\ V2.vst3

screenshot_5194

(Edited to get rid of stupid markdown) (edited again so my XML could be included - sigh) (edited again with an IMAGE of the XML stuff - more sighs)

DropSnorz commented 3 years ago

Thank you for these precisions and extra logs.

When I ran from a terminal Window, I saw an illegal access from Java

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.

Check the attached image where you identify (correctly) the plugin version of the Stage-73 but you don't seem to know who is the manufacturer nor the category. Gig Performer (see image in my original post) correctly identifies both.

If I use our own scanner from the command line on that VST (by the way, it's the VST3 version that is failing with OwlPlug) I correctly retrieve all the info

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
DavidJameson commented 2 years ago

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

screenshot_5239

DavidJameson commented 2 years ago

is a VST/VST2 but it can't be natively scanned by OwlPlug.

Why not?

DropSnorz commented 2 years ago

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) ?

DavidJameson commented 2 years ago

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?

DropSnorz commented 2 years ago

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.

ArturiaPass

49459 DEBUG c.o.core.components.TaskRunner - Task submited to queue - com.owlplug.core.tasks.PluginSyncTask 
49490 DEBUG c.o.core.components.TaskRunner - Task submitted to executor - com.owlplug.core.tasks.PluginSyncTask 
49509 INFO  c.owlplug.core.tasks.PluginSyncTask - Plugin Sync task started
49894 DEBUG c.owlplug.core.tasks.PluginSyncTask - 2 plugins collected
50286 DEBUG c.owlplug.core.tasks.PluginSyncTask - Load plugin using native discovery: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Attempting to load VST: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Creating VST instance: Stage-73 V2
Initialising VST: Stage-73 V2 (3.36.19.984)
61146 DEBUG c.owlplug.core.tasks.PluginSyncTask - Load plugin using native discovery: /Library/Audio/Plug-ins/VST3/Stage-73 V2.vst3
62911 INFO  c.owlplug.core.tasks.PluginSyncTask - Plugin Sync task complete

Sometimes, only the VST2 plugin crashes during sync.

ArturiaVST2Unstable

86283 DEBUG c.o.core.components.TaskRunner - Task submited to queue - com.owlplug.core.tasks.PluginSyncTask 
86285 DEBUG c.o.core.components.TaskRunner - Task submitted to executor - com.owlplug.core.tasks.PluginSyncTask 
86321 INFO  c.owlplug.core.tasks.PluginSyncTask - Plugin Sync task started
86558 DEBUG c.owlplug.core.tasks.PluginSyncTask - 2 plugins collected
86839 DEBUG c.owlplug.core.tasks.PluginSyncTask - Load plugin using native discovery: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Attempting to load VST: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Creating VST instance: Stage-73 V2
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000150d0e5d6, pid=1132, tid=775
#
# JRE version: OpenJDK Runtime Environment AdoptOpenJDK (14.0.2+12) (build 14.0.2+12)
# Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (14.0.2+12, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [Stage-73 V2+0x5fc5d6]  GetPluginFactory+0x589a6
#
# 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:
# /var/folders/_t/p7rkh9kd0lz5m6j5w6w4d4v40000gn/T//hs_err_pid1132.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Sometimes, only the VST3 plugin crashes during sync.

ArturiaVST3Unstable

256075 DEBUG c.o.core.components.TaskRunner - Task submited to queue - com.owlplug.core.tasks.PluginSyncTask 
256076 DEBUG c.o.core.components.TaskRunner - Task submitted to executor - com.owlplug.core.tasks.PluginSyncTask 
256082 INFO  c.owlplug.core.tasks.PluginSyncTask - Plugin Sync task started
256288 DEBUG c.owlplug.core.tasks.PluginSyncTask - 2 plugins collected
256516 DEBUG c.owlplug.core.tasks.PluginSyncTask - Load plugin using native discovery: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Attempting to load VST: /Library/Audio/Plug-ins/VST/Stage-73 V2.vst
Creating VST instance: Stage-73 V2
Initialising VST: Stage-73 V2 (3.36.19.984)
258492 DEBUG c.owlplug.core.tasks.PluginSyncTask - Load plugin using native discovery: /Library/Audio/Plug-ins/VST3/Stage-73 V2.vst3
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000014d3b75d6, pid=1019, tid=775
#
# JRE version: OpenJDK Runtime Environment AdoptOpenJDK (14.0.2+12) (build 14.0.2+12)
# Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (14.0.2+12, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [Stage-73 V2+0x5fc5d6]  GetPluginFactory+0x589a6
#
# 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:
# /Users/vagrant/hs_err_pid1019.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

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.

DavidJameson commented 2 years ago

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.

Bide-UK commented 2 years ago
DropSnorz commented 2 years ago

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). 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 🤞

DavidJameson commented 2 years ago

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 https://github.com/DropSnorz/OwlPlug/issues/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 https://github.com/DropSnorz/OwlPlug/issues/105#issuecomment-1066066036, 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

DropSnorz commented 2 years ago

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,

DavidJameson commented 2 years ago

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 https://github.com/DropSnorz/OwlPlug/issues/105#issuecomment-1066087146, 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.

DropSnorz commented 2 years ago

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.

DavidJameson commented 2 years ago

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.