Removing OpenAL Object From NSDictionary Crashes While Playing

Discussion in 'Mac Programming' started by Darkroom, Jan 13, 2010.

  1. Darkroom Guest

    Darkroom

    Joined:
    Dec 15, 2006
    Location:
    Montréal, Canada
    #1
    i've recently started learning OpenAL. for the most part it's been
    smooth going. however, i'm now having a problem removing an OpenAL
    object from an array if the source is currently playing. doing so
    crashes my app after deallocating the object. removing a sound while
    it's not playing works fine.

    subsequently, my immediate course of action was to query
    AL_SOURCE_STATE before removing the sound. if the source is playing,
    stop the sound (alSourceStop) and then remove the object.
    surprisingly, this didn't work and my app still crashed after
    deallocation. some of the sounds i plan on using are for background
    music, so they will be looping and quite lengthy compared to a short
    sound effect. therefore, querying the source's state before removing
    the sound only when the source is finished wouldn't really be an
    option even if it did work.

    what does seem to work is setting a timer to remove the sound sometime
    after the sound has stopped, although following this path would be insecure
    and problematic in the long run.


    Code:
    // Controller Class
    - (void)removeSoundWithID:(NSUInteger)soundID
           {
           NSString *soundFile = [self keyForSoundID:soundID];
           if(!soundFile) return;
    
           [soundDictionary removeObjectForKey:soundFile];
           }
    
    
    
    //OpenAL Sound Object
    - (void)dealloc
           {
           alDeleteSources(1, &sourceID);
    
           for (NSNumber *tmpSourceID in temporarySounds)
                   {
                   NSUInteger srcID = [tmpSourceID unsignedIntegerValue];
                   alDeleteSources(1, &srcID);
                   }
    
           [temporarySounds release];
    
           alDeleteBuffers(1, &bufferID);
           if (bufferData)
                   {
                   free(bufferData);
                   bufferData = NULL;
                   }
    
           [sourceFileName release];
    
           [super dealloc];
           NSLog(@"Deallocation Complete");
           }
    
     
  2. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #2
    What does the stack trace look like when it crashes?
     
  3. Darkroom thread starter Guest

    Darkroom

    Joined:
    Dec 15, 2006
    Location:
    Montréal, Canada
    #3
    there doesn't seem to be one? it's a bizarre crash, since the app simply becomes non responsive. when that happens the console logs what you can see in the attached image. however, i have to manually quit the app (you can see the stop button is still enabled). after i quit the app, the following is displayed in the console:

    Code:
    kill
    Current language:  auto; currently asm
    quit
    
    The Debugger has exited with status 0.(gdb)
    
    or sometimes it will say

    Code:
    kill
    error while killing target (killing anyway): warning: error on line 1987 of "/SourceCache/gdb/gdb-967/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
    Current language:  auto; currently asm
    quit
    
    The Debugger has exited with status 0.(gdb)
    
    while this is an iPhone project, i'm assuming the problem is with OpenAL so that's why i've posted the question in this forum.
     

    Attached Files:

  4. Darkroom thread starter Guest

    Darkroom

    Joined:
    Dec 15, 2006
    Location:
    Montréal, Canada
    #4
    so i found out that the cause was because of apple's alBufferDataStaticProc(), which is from their published sample code that also crashes, and that simply using the traditional alBufferData() cleared the issue.

    all is well. except for apple's ghetto sample code
     

Share This Page