MidiDeviceProvider.isDeviceSupported() throwing a NullPointerException

[eclab]

I have an Edisyn user who is unable to load CoreMIDI4J with an unusual exception, which I include below. Notice the end, where it appears that CoreMidiDeviceProvider is calling javax.sound.midi.spi.MidiDeviceProvider.isDeviceSupported(), which is in turn generating a NullPointerException. He's running 10.13.6, I'm not sure which version of Java (I'll post it when I find out). Any idea why CoreMIDI4J might be failing? Could it be a device error? I understand this may be a low-level Java issue, not CoreMIDI4J; it's not clear.

java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at edisyn.Midi.updateDevices(Midi.java:192) at edisyn.Midi.<clinit>(Midi.java:297) at edisyn.Synth.<init>(Synth.java:1208) at edisyn.synth.tuning.Tuning.<init>(Tuning.java:31) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at edisyn.Synth.instantiate(Synth.java:283) at edisyn.Synth.instantiate(Synth.java:263) at edisyn.gui.Favorites.doNewSynthDialog(Favorites.java:187) at edisyn.Synth.doNewSynthPanel(Synth.java:7394) at edisyn.Edisyn.main(Edisyn.java:52) Caused by: java.lang.NullPointerException at javax.sound.midi.spi.MidiDeviceProvider.isDeviceSupported(MidiDeviceProvider.java:52) at javax.sound.midi.MidiSystem.getMidiDevice(MidiSystem.java:221) at uk.co.xfactorylibrarians.coremidi4j.CoreMidiDeviceProvider.getMidiDeviceInfo(CoreMidiDeviceProvider.java:739) ... 18 more

[eclab]

Some digging into javax.sound.midi.spi.MidiDeviceProvider.isDeviceSupported() suggests that it's probably calling getMidiDeviceProviders(), which calls getProviders(MidiDeviceProvider.class), which calls JDK13Services.getProviders(MidiDeviceProvider.class). And this is probably returning null when it's supposed to always return a List, even of length 0. Is CoreMIDI4J overriding or implementing any of this and returning null incorrectly by any chance?

[eclab]

Later on Edisyn calls getMIDIDeviceInfo() and produces a similar error, see below. I note that getMIDIDeviceInfo() also calls getMidiDeviceProviders() as well, probably once again generating an incorrect null.

Exception in thread "main" java.lang.ExceptionInInitializerError at edisyn.Synth.<init>(Synth.java:1208) at edisyn.synth.tuning.Tuning.<init>(Tuning.java:31) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at edisyn.Synth.instantiate(Synth.java:283) at edisyn.Synth.instantiate(Synth.java:263) at edisyn.gui.Favorites.doNewSynthDialog(Favorites.java:187) at edisyn.Synth.doNewSynthPanel(Synth.java:7394) at edisyn.Edisyn.main(Edisyn.java:52) Caused by: java.lang.NullPointerException at javax.sound.midi.MidiSystem.getMidiDeviceInfo(MidiSystem.java:196) at edisyn.Midi.updateDevices(Midi.java:199) at edisyn.Midi.<clinit>(Midi.java:297) ... 12 more

[DerekCook]

Hi,

in our code isDeviceSupported(Info) I cannot see anything that would cause a null pointer exception

And reading your stack traces, does it not imply the exceptions are being thrown lower down in Java itself?

It would be useful if you could provide some example code that makes the issue reproducible and we could then try running it here to see what happens.

[eclab]

This will be tough -- it's a bug on someone else's computer who has left me a bug report for Edisyn. :-(

I don't think it's in isDeviceSupported(...), but I suspect the problem is likely that getMidiDeviceProviders() is incorrectly returning null, and methods like isDeviceSupported(...) are bombing because they're expecting the providers to be non-null.

[DerekCook]

I feel for you.

The other thing which is strange is

uk.co.xfactorylibrarians.coremidi4j.CoreMidiDeviceProvider.getMidiDeviceInfo(CoreMidiDeviceProvider.java:739)

Because 739 is a blank line!

Can you get a complete stack trace? It would be worth seeing what the "18 more are"?

Unfortunately unless we can get a reproducible example, I do not know what to do. Two things I guess we could try

1. If you remove CoreMIDI4J from the system do you get the same problem. Assuming at this point we are just iterating devices and we know SYSEX aint going to work, it would be interest to see if you have the same issue

2. If point 1 indicates it is coremidi4j, Instrument the code in a debug build to try and see if we can see what is happening.

[eclab]

On Aug 28, 2021, at 11:29 AM, Derek Cook ***@***.***> wrote: The other thing which is strange is uk.co.xfactorylibrarians.coremidi4j.CoreMidiDeviceProvider.getMidiDeviceInfo(CoreMidiDeviceProvider.java:739) Because 739 is a blank line!

Pretty sure he's using a version of Edisyn with CoreMIDI4J 1.6. I'll check though.

Can you get a complete stack trace? It would be worth seeing what the "18 more are"?

Actually I'm not sure how to get Java to do that. Even so, it'd probably be stuff higher up in the echelon, like GUI events.

If you remove CoreMIDI4J from the system do you get the same problem. Assuming at this point we are just iterating devices and we know SYSEX aint going to work, it would be interest to see if you have the same issue

I'm way ahead of you. We'll see if the same problem occurs without CoreMIDI4J. Sean

[brunchboy]

I am glad you jumped on this one, Derek, as I am in the final stages of cleaning out our old home in preparation for closing on the sale on Tuesday morning. It has been a crazy, stressful summer but I hope to get back to my open-source projects this fall!

[eclab]

On Aug 28, 2021, at 11:39 AM, Sean Luke ***@***.***> wrote: > On Aug 28, 2021, at 11:29 AM, Derek Cook ***@***.*** ***@***.***>> wrote: > > The other thing which is strange is > uk.co.xfactorylibrarians.coremidi4j.CoreMidiDeviceProvider.getMidiDeviceInfo(CoreMidiDeviceProvider.java:739) > > Because 739 is a blank line >

He's using CoreMIDI4j 1.6. Below a disassembly from my 1.6 jar file. It appears that line 739 is the 40:aload 5 just before the call to `MidiSystem.getMidiDevice(...)`. I note that the very first thing `getMidiDevice()` does is call `MidiSystem.getMidiDeviceProviders()`, which should never be null, and then iterates through it. That's where the null pointer exception happens -- `MidiSystem.getMidiDeviceProviders` is returning null (likely because `JDK13Services.getProviders(providerClass)(MidiDeviceProvider.class)` is returning null, even though it's always supposed to be non-null). So I just asked him to run a special version without CoreMIDI4J. And it runs fine! Without sysex of course, which is broken on the Mac. All devices are disconnected from the Mac, and MidiKeys and MidiMonitor are running so Edisyn has at least one input and one output. This tells me that it is likely that CoreMIDI4J is triggering this. :-( :-( He's on Java 8_305 on 10.15.7 Catalina. I'm running fine on Java 8_116 on 10.13.6 High Sierra. What could be happening in CoreMIDI4j that would cause JDK13Services.getProviders(providerClass)(MidiDeviceProvider.class) to incorrectly return null? Sean ` public static javax.sound.midi.MidiDevice$Info[] getMidiDeviceInfo(); Code: 0: invokestatic #82 // Method getSystemMidiDeviceInfo:()[Ljavax/sound/midi/MidiDevice$Info; 3: astore_0 4: invokestatic #16 // Method isLibraryLoaded:()Z 7: ifeq 147 10: new #125 // class java/util/ArrayList 13: dup 14: aload_0 15: arraylength 16: invokespecial #126 // Method java/util/ArrayList."<init>":(I)V 19: astore_1 20: aload_0 21: astore_2 22: aload_2 23: arraylength 24: istore_3 25: iconst_0 26: istore 4 28: iload 4 30: iload_3 31: if_icmpge 128 34: aload_2 35: iload 4 37: aaload 38: astore 5 40: aload 5 42: invokestatic #127 // Method javax/sound/midi/MidiSystem.getMidiDevice:(Ljavax/sound/midi/MidiDevice$Info;)Ljavax/sound/midi/MidiDevice; 45: astore 6 47: aload 6 49: instanceof #128 // class javax/sound/midi/Sequencer 52: ifne 79 55: aload 6 57: instanceof #129 // class javax/sound/midi/Synthesizer 60: ifne 79 63: aload 6 65: instanceof #36 // class uk/co/xfactorylibrarians/coremidi4j/CoreMidiDestination 68: ifne 79 71: aload 6 73: instanceof #28 // class uk/co/xfactorylibrarians/coremidi4j/CoreMidiSource 76: ifeq 88 79: aload_1 80: aload 5 82: invokeinterface #86, 2 // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z 87: pop 88: goto 122 91: astore 6 93: getstatic #51 // Field java/lang/System.err:Ljava/io/PrintStream; 96: new #52 // class java/lang/StringBuilder 99: dup 100: invokespecial #53 // Method java/lang/StringBuilder."<init>":()V 103: ldc #131 // String Problem obtaining MIDI device which supposedly exists: 105: invokevirtual #55 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 108: aload 6 110: invokevirtual #132 // Method javax/sound/midi/MidiUnavailableException.getMessage:()Ljava/lang/String; 113: invokevirtual #55 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 116: invokevirtual #58 // Method java/lang/StringBuilder.toString:()Ljava/lang/String; 119: invokevirtual #59 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 122: iinc 4, 1 125: goto 28 128: aload_1 129: aload_1 130: invokeinterface #133, 1 // InterfaceMethod java/util/List.size:()I 135: anewarray #66 // class javax/sound/midi/MidiDevice$Info 138: invokeinterface #134, 2 // InterfaceMethod java/util/List.toArray:([Ljava/lang/Object;)[Ljava/lang/Object; 143: checkcast #135 // class "[Ljavax/sound/midi/MidiDevice$Info;" 146: areturn 147: goto 179 150: astore_1 151: getstatic #51 // Field java/lang/System.err:Ljava/io/PrintStream; 154: new #52 // class java/lang/StringBuilder 157: dup 158: invokespecial #53 // Method java/lang/StringBuilder."<init>":()V 161: ldc #136 // String Problem trying to determine native library status: 163: invokevirtual #55 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 166: aload_1 167: invokevirtual #137 // Method uk/co/xfactorylibrarians/coremidi4j/CoreMidiException.getMessage:()Ljava/lang/String; 170: invokevirtual #55 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 173: invokevirtual #58 // Method java/lang/StringBuilder.toString:()Ljava/lang/String; 176: invokevirtual #59 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 179: aload_0 180: areturn Exception table: from to target type 40 88 91 Class javax/sound/midi/MidiUnavailableException 4 146 150 Class uk/co/xfactorylibrarians/coremidi4j/CoreMidiException LineNumberTable: line 727: 0 line 731: 4 line 733: 10 line 735: 20 line 739: 40 line 741: 47 line 746: 79 line 754: 88 line 750: 91 line 752: 93 line 735: 122 line 758: 128 line 766: 147 line 762: 150 line 764: 151 line 768: 179 LocalVariableTable: Start Length Slot Name Signature 47 41 6 device Ljavax/sound/midi/MidiDevice; 93 29 6 e Ljavax/sound/midi/MidiUnavailableException; 40 82 5 candidate Ljavax/sound/midi/MidiDevice$Info; 20 127 1 workingDevices Ljava/util/List; 151 28 1 e Luk/co/xfactorylibrarians/coremidi4j/CoreMidiException; 4 177 0 allInfo [Ljavax/sound/midi/MidiDevice$Info; `

[DerekCook]

I am glad you jumped on this one, Derek, as I am in the final stages of cleaning out our old home in preparation for closing on the sale on Tuesday morning. It has been a crazy, stressful summer but I hope to get back to my open-source projects this fall!

My work is pretty stupid as well, but back for the weekend, so a little time to try and help Sean. Hope you have a less stressful autumn

[DerekCook]

He's using CoreMIDI4j 1.6. Below a disassembly from my 1.6 jar file. It appears that line 739 is the 40:aload 5 just before the call to MidiSystem.getMidiDevice(...). I note that the very first thing getMidiDevice() does is call MidiSystem.getMidiDeviceProviders(), which should never be null, and then iterates through it. That's where the null pointer exception happens -- MidiSystem.getMidiDeviceProviders is returning null (likely because JDK13Services.getProviders(providerClass)(MidiDeviceProvider.class) is returning null, even though it's always supposed to be non-null). So I just asked him to run a special version without CoreMIDI4J. And it runs fine!

OK, thanks for checking. It was worth clarifying that. I will need to do some thinking about it. As I said before, a reproducible would be really helpful if you can do that. And is there anything we need to know about your user's environment that might help.

The only other option is to build a debug version of the library with some tracing in to try and see what is happening.

[eclab]

I just got feedback from the user, currently running a test version of Edisyn that is missing CoreMIDI4J, and he's generating NullPointerExceptions from javax.sound.midi.MidiSystem.getMidiDeviceInfo, which likewise is almost certainly triggered by null incorrectly being returned from MidiSystem.getMidiDeviceProviders(). So hold off for a bit, I have some evidence that it might not be CoreMIDI4J. Frustrating.

…

On Aug 28, 2021, at 1:36 PM, Derek Cook ***@***.***> wrote: He's using CoreMIDI4j 1.6. Below a disassembly from my 1.6 jar file. It appears that line 739 is the 40:aload 5 just before the call to MidiSystem.getMidiDevice(...). I note that the very first thing getMidiDevice() does is call MidiSystem.getMidiDeviceProviders(), which should never be null, and then iterates through it. That's where the null pointer exception happens -- MidiSystem.getMidiDeviceProviders is returning null (likely because JDK13Services.getProviders(providerClass)(MidiDeviceProvider.class) is returning null, even though it's always supposed to be non-null). So I just asked him to run a special version without CoreMIDI4J. And it runs fine! OK, thanks for checking. It was worth clarifying that. I will need to do some thinking about it. As I said before a reproducible would be really helpful if you can do that. The only other option is to build a debug version of the library with some tracing in to try and see what is happening. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://secure-web.cisco.com/1y-aFRgmQct7JAphpq_yCA1DwRSjiH1tYdaZvd-hzUNz5dBBMn3wEanuYlfyIsR1X8pUyCWNlkGytIQlLe8IExwfge7YlRm3leFeHegYmDzaNY37NP9SlWzWM-W2HInzJezOkShFoAEQ79Ke5t30TtmXIj2FkwauvMFKjtqwS_8WXXYIt2PGMWAfWMzSmGmI75FmUDIqAFT04uFFbUc9s7S24j6aIHH2_IOcXkOm-kdJfLS6bAkUwwu_Bb5hYhs9bZIC2mqtmsbaBtoX4A8b621R311DEnA_pLucsRQyLQeKPUe8mMQgQI--69zvG5yiBZ9Do4kr8I-jy3shAoFxkP2kzcV0PkrJhcF2HinkCgdWYRUqUur-6xIS5T_CNUv93_74k8vW4UjVaAipObweM-LMRpFjnVO6aJ4wXb5DD8i79n99JBDERz-dmyotdx_Jc/https%3A%2F%2Fgithub.com%2FDerekCook%2FCoreMidi4J%2Fissues%2F43%23issuecomment-907660289>, or unsubscribe <https://secure-web.cisco.com/1LvcwK4Natc-VESJPZTsUc6SnnWoktKqCsvyPuoQ7OmEv6qpT0KsS6wxGc9u2jIh4QAvGgs94yKoonHauzGxKEaY8-1Hn2tVBWC0FIpcjSFPOM2V4tG-TRGW0SKXhD7KaRnA1yMCR1UHZhBBvFStrfG2SLp_sMOAxcUSXV61Lu7fVF!%20VAHKakVvLEg1qSzXRBXzp1Lp4V42qK9BCqXd5IV2BqynyFR_LsAmzgkkuK7Hy3LR38cTHTWzQbvRgknRk5dHvshmIDpNknfi6BWYmGsrJ_rsvarHqwzh0uQDOc1PwXEZdH1uIJndHmmlXEiBqlpEEeb97r43wJybRVrfUqVALE-ayfUH85wYhsFwqhr9eFhvSWM2yy2y9hY26fZ8urdfoP9krD7qAQHhSzazdfWnwQk5fub_9x1eHBLbbfBB-I434sqla33CKHnK0-AwQfp/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADAZDVG67JNBEDPLATSXYH3T7ENCZANCNFSM5C5P3BOQ>. 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>.

[DerekCook]

OK, good progress. It is always hard nailing things down remotely. We won't do anything for now, but keep us posted if you do get a reproducible case that we can help you on if a fix to CoreMIDI4J is needed.

Once you know the issue, then perhaps we can put some guard code in to either trap the cause that leads to the null, or to do a work around if we get a null.

[eclab]

My user removed everything from /Library/Java or from ~/Library/Java (not sure which from his email) and Edisyn/CoreMIDI4J now works fine. So now I want to know what was in that directory.

I'm closing the issue with my thanks and apologies.