next »

[marktronic]

We're seeing crashes (EXC_BAD_ACCESS) on app termination with stacks that look like:

0 0x001add84 BASS_ChannelIsSliding + 6548
1 0x001ae0ec BASS_ChannelIsActive + 572
2 0x001c0304 BASS_StreamFree + 16
3 0x001976f8 BASS_MIDI_StreamCreateFile + 544
4 0x00197798 BASS_MIDI_StreamCreateFile + 704
7 libsystem_c.dylib 0x31de9f1f __cxa_finalize + 222
8 libsystem_c.dylib 0x31db59dd exit + 12
9 UIKit 0x3274dc4b -[UIApplication _terminateWithStatus:] + 330
10 UIKit 0x3274a4cf -[UIApplication _handleApplicationSuspend:eventInfo:] + 2402
11 UIKit 0x326d9d17 -[UIApplication handleEvent:withNewEvent:] + 2030
12 UIKit 0x326d93bf -[UIApplication sendEvent:] + 54
13 UIKit 0x326d8d2d _UIApplicationHandleEvent + 5808

This crash happens when the app is closing so it's not a huge deal in terms of impacting user experience, but our crash reporting service has already logged almost 187k instances of this crash. We do setup and cleanup something like this:

    m_stream = BASS_MIDI_StreamCreate( 127, BASS_STREAM_DECODE, 0 );
    BASS_SetConfig(BASS_CONFIG_MIDI_VOICES, MAX_POLYPHONY );

    // load soundfont, etc....

    // cleanup
    if( m_stream ) BASS_StreamFree( m_stream );
    BASS_Free();
    m_stream = NULL;

I have verified that we are hitting the StreamFree code when the app is terminating, but there seems to be something happening after the stream is freed that is crashing the app.

Has anyone else seen this? I can provide more info if that would be helpful!

Thanks!

[Ian @ un4seen]

The function names in the call stack won't necessarily be correct (it's just the symbol/function that precedes the address), but it does at least tell us which library it's in, and it looks like the problem originates from BASSMIDI in this case. Do you happen to be using either packed soundfonts or BASS_MIDI_StreamGetChannel? I'll send you a debug version to get some additional info (please confirm that you're using the iOS version).

[marktronic]

The function names in the call stack won't necessarily be correct (it's just the symbol/function that precedes the address), but it does at least tell us which library it's in, and it looks like the problem originates from BASSMIDI in this case. Do you happen to be using either packed soundfonts or BASS_MIDI_StreamGetChannel? I'll send you a debug version to get some additional info (please confirm that you're using the iOS version).

Hi Ian! Thanks for the quick reply!

We are using the iOS version found here: www.un4seen.com/stuff/bass24-iphone.zip

We are using mostly packed soundfonts and are not making any calls BASS_MIDI_StreamGetChannel. Here is the code we use to load our soundfont:

    // create bass stream - 127 channels one for each note
    m_stream = BASS_MIDI_StreamCreate( 127, BASS_STREAM_DECODE, 0 );
       
    BASS_SetConfig(BASS_CONFIG_MIDI_VOICES, MAX_POLYPHONY );
   
    // load new sound font
    if( HSOUNDFONT sfNew = BASS_MIDI_FontInit( filepath, 0 ) )
    {
        BASS_MIDI_FONT sf;
        sf.font = sfNew;
        sf.preset = -1;                                 // use all presets
        sf.bank = 0;                                    // use default bank(s)

        // ....
               
        // load font to prevent crackling in case it is packed
        BASS_MIDI_FontLoad( sf.font, sf.preset, sf.bank );
       
        // set default soundfont
        BASS_MIDI_StreamSetFonts( 0, &sf, 1 );

        // set for output stream too
        BASS_MIDI_StreamSetFonts( m_stream, &sf, 1 );

        // free old soundfont
        BASS_MIDI_FontFree( m_sf );

        // set our font
        m_sf = sfNew;
    }

A debug version of the library would be great. I can reliably reproduce this so if there's any way I can get more helpful info to you, I'd love to help.

[marktronic]

The function names in the call stack won't necessarily be correct (it's just the symbol/function that precedes the address), but it does at least tell us which library it's in, and it looks like the problem originates from BASSMIDI in this case. Do you happen to be using either packed soundfonts or BASS_MIDI_StreamGetChannel? I'll send you a debug version to get some additional info (please confirm that you're using the iOS version).

If you'd like to send me the build info over email, message me and I can provide an email. Thanks!

[Ian @ un4seen]

We are using mostly packed soundfonts...

Are you calling BASS_MIDI_FontFree to free the soundfonts before the app terminates? If not, please try that. With dynamic libraries, reference counts ensure a consistent library uninitialization/unloading order, eg. BASSMIDI depends on BASS, increasing its reference count, so BASSMIDI has to be uninitialized before BASS can be. That isn't possible with static libraries (as on iOS), and what I suspect may be happening in your case is that BASS is being uninitialized before BASSMIDI is, and that is resulting in problems when BASSMIDI tries to free the decoder used to unpack the soundfont (if BASS_MIDI_FontFree hasn't been called on it).

I'll look into tweaking things so that any library uninitialization order won't ever result in a crash. In fact, uninitialization can probably be skipped to a large extent on iOS, as the process is terminating (it isn't just a library being unloaded) and the OS can reclaim the resources.

[marktronic]

We are using mostly packed soundfonts...

Are you calling BASS_MIDI_FontFree to free the soundfonts before the app terminates? If not, please try that. With dynamic libraries, reference counts ensure a consistent library uninitialization/unloading order, eg. BASSMIDI depends on BASS, increasing its reference count, so BASSMIDI has to be uninitialized before BASS can be. That isn't possible with static libraries (as on iOS), and what I suspect may be happening in your case is that BASS is being uninitialized before BASSMIDI is, and that is resulting in problems when BASSMIDI tries to free the decoder used to unpack the soundfont (if BASS_MIDI_FontFree hasn't been called on it).

Thanks Ian! That did the trick. Thanks for the help.