Topic: BASSMIDI iOS 9 crash on _dyld_start

[Nicholas]

I was trying out the new 2.4.14 version of BASSMIDI and ran into a reproducible crash.

On newer iOS device targets everything seems to work great.

But when testing against our oldest supported platform (an iPad 2--which is notably only 32-bit ARMv7--running iOS 9.3.5), it appears the library cannot be loaded.  If you add the framework to your Xcode project the usual way but don't call any BASSMIDI functions, the app runs without trouble.  But after adding and compiling any line of code that requires actually linking to a BASSMIDI function, there is a crash immediately at startup during _dyld_start (looking at the disassembly it's right after a call to dyldbootstrap::start).  The only other call stack frame is dyld_fatal_error which has a trap opcode, triggering an EXC_ARM_BREAKPOINT exception.

Otherwise, there is no output on the terminal.

My guess is that some 64-bit-only code got mixed into the library, preventing it from being loaded on arm7.

Please let me know if you need any other information to help track the problem down.  Thanks!



Hmm, as a bonus, there appears to be a problem when loading the new BASSMIDI Android library, too.  Has something changed or should the .so files be a drop-in replacement for the old ones?  I'm getting an exception on my System.loadLibrary("bassmidi") line, which mirrors the iOS problem almost directly:

"A/DEBUG: Abort message: 'JNI DETECTED ERROR IN APPLICATION: JNI NewGlobalRef called with pending exception java.lang.ClassNotFoundException: Didn't find class "com.un4seen.bass.BASSMIDI$BASS_MIDI_EVENT" on path: [... lots of file paths ...]"

Although this one is happening on a Galaxy Tab S6 Lite (SM-P610) which is 64-bit ARMv8-A, running Android 12.

[Ian @ un4seen]

Oops! This is because BASSMIDI 2.4.14 is using the clock_gettime function without first checking that it is available, which it isn't before iOS 10. A new build that does check first is up on the BASS webpage now, so please re-download to get that. The macOS version is also affected by this issue (clock_gettime first appeared in macOS 10.12), so a new build of that is up too.

In the Android case, it looks like the BASS Java classes may have been removed from the app, so BASSMIDI can't find them. Make sure your ProGuard rules includes the following:

Code: [Select]

-keep class com.un4seen.bass.** {*;}


[Nicholas]

That fixed the iOS problem, thanks!  (So fast!)

I didn't have any luck with your Android suggestion, unfortunately.  Are ProGuard requirements something you would have expected to change between BASSMIDI versions?  If I drop the previous arm64-v8a/libbassmidi.so into the folder, the app works perfectly.  If I drop the new .so in the folder, it gives that startup crash with no other changes.

I tried adding your -keep line to our ProGuard rules and it didn't have any effect.  I also tried a -donotnote line and that also had no impact.

Looking at logcat again, this looks like a maybe-useful native stack trace line (that hopefully doesn't just point to the same NewGlobalRef problem from before) that follows just after the Java stack trace:

#10 pc 0000000000019228  .../arm64/libbassmidi.so (JNI_OnLoad+72) (BuildId: 1d4db8085ef3ffed3d0330b501f609141fc7fe86)

[Ian @ un4seen]

In the past, BASSMIDI would try get the BASS_MIDI_EVENT Java class when it's needed, eg. within a BASS_MIDI_StreamEvents call. But that had problems if the call was in a native thread, like in this MIDIFILTERPROC case:

   www.un4seen.com/forum/?topic=13225.msg134688#msg134688

So BASSMIDI was changed to get the BASS_MIDI_EVENT class in its JNI_OnLoad function, and it's that that's failing in your case, most likely because the class was removed by ProGuard. A new build that clears the ClassNotFoundException exception is up on the BASS page now, so please re-download to get that. Let me know if you do still see the crash happening with it.

If you are using any BASSMIDI Java classes in the app then you will probably still have a problem with that. If so, to confirm whether it is ProGuard-related, please try disabling ProGuard entirely (eg. "minifyEnabled false") and see if the problem still happens then.

[Nicholas]

On Friday I'd deleted the zip download with the new version, so when I went to get another copy just now to do more testing, I noticed that bassmidi24-android.zip seems to have been updated. (Curiously, the .so files seem to have a timestamp from an hour in the future, so I'm guessing you just updated these and you're probably in a different time zone.)

In any event, trying the new build, they always work regardless of any Proguard settings.

Does that sound like something that should have happened?  Or have we entered voodoo bug territory where behavior is changing unexpectedly?  Thanks!

[Ian @ un4seen]

Yes, an update was put up a few hours earlier, as I wrote above

The update should avoid the ClassNotFoundException exception (sounds like it did indeed for you), but wouldn't make any difference to whether BASSMIDI classes (eg. BASS_MIDI_EVENT/FONT/MARK) are being removed from the app. Is your app using any such classes in BASSMIDI function calls, and if so, are those calls successful?

[Nicholas]

Wow, I totally missed that sentence in your last post, sorry!  It's good to hear it was expected behavior.

We use all the same (completely native, C) BASS code across all our platforms, so outside of the System.loadLibrary call, the Java side of our Android app doesn't know anything about it.  That sounds like the reason I hadn't run into this problem before.

Thanks again for all of this.  I believe that gets me 100% back up and running with the new BASSMIDI version.

[Ian @ un4seen]

We use all the same (completely native, C) BASS code across all our platforms, so outside of the System.loadLibrary call, the Java side of our Android app doesn't know anything about it.  That sounds like the reason I hadn't run into this problem before.

Ah yes, that would explain it. You don't need the Java classes then, and so don't need BASSMIDI to try getting them.