crash in using soundNamed:

  • I have the following code to generate a list of sounds for a menu item:

    - (NSArray *) sounds
    {
        NSMutableArray * sounds = [NSMutableArray array];

        NSArray * directories = [NSArray arrayWithObjects: @"/System/
    Library/Sounds", @"/Library/Sounds",
                                    [NSHomeDirectory()
    stringByAppendingPathComponent: @"Library/Sounds"], nil];
        BOOL isDirectory;
        NSEnumerator * soundEnumerator;
        NSString * sound;

        NSString * directory;
        NSEnumerator * enumerator = [directories objectEnumerator];
        while ((directory = [enumerator nextObject]))
            if ([[NSFileManager defaultManager] fileExistsAtPath:
    directory isDirectory: &isDirectory] && isDirectory)
            {
                    soundEnumerator = [[[NSFileManager defaultManager]
    directoryContentsAtPath: directory] objectEnumerator];
                    while ((sound = [soundEnumerator nextObject]))
                    {
                        sound = [sound stringByDeletingPathExtension];
                        if ([NSSound soundNamed: sound])
                            [sounds addObject: sound];
                    }
            }

        return sounds;
    }

    Some users are reporting crashes when using this with custom sounds
    in one of the directories.

    I'm a bit confused on how this could crash in soundNamed. A crash log
    is:

    Thread 0 Crashed:
    0 com.apple.AppKit 0x93436ae4 -[NSSound _postInitialization] + 749
    1 com.apple.AppKit 0x9369d868 -[NSSound
    initWithContentsOfURL:byReference:] + 256
    2 com.apple.AppKit 0x9369e7a3 +[NSSound _searchForSoundNamed:] + 626
    3 com.apple.AppKit 0x9369e8a5 +[NSSound soundNamed:] + 203
    4 org.m0k.transmission 0x00010829 -[PrefsController sounds] + 339
    5 com.apple.AppKit 0x934e200b -[NSBinder
    _valueForKeyPath:ofObject:mode:raisesForNotApplicableKeys:] + 733
    6 com.apple.AppKit 0x934e1c9e -[NSBinder
    valueForBinding:resolveMarkersToPlaceholders:] + 192
    7 com.apple.AppKit 0x935155a5 -[NSSelectionBinder
    _adjustObject:mode:observedController:observedKeyPath:context:editableSt
    ate:adjustState:] + 1103
    8 com.apple.AppKit 0x934e149a -[NSValueBinder
    _observeValueForKeyPath:ofObject:context:] + 280
    9 com.apple.AppKit 0x9351514c -[NSSelectionBinder
    observeValueForKeyPath:ofObject:change:context:] + 308
    10 com.apple.AppKit 0x934e1271 -[NSBinder
    _performConnectionEstablishedRefresh] + 78
    11 com.apple.AppKit 0x934d98da -[NSObject(NSKeyValueBindingCreation)
    bind:toObject:withKeyPath:options:] + 763

    Thanks a lot,
    Mitch Livingston
  • On Oct 24, 2007, at 12:07 PM, Mitchell Livingston wrote:

    > Some users are reporting crashes when using this with custom sounds
    > in one of the directories.
    >
    > I'm a bit confused on how this could crash in soundNamed. A crash
    > log is:
    >
    > Thread 0 Crashed:
    > 0 com.apple.AppKit 0x93436ae4 -[NSSound _postInitialization] + 749
    > 1 com.apple.AppKit 0x9369d868 -[NSSound
    > initWithContentsOfURL:byReference:] + 256
    > 2 com.apple.AppKit 0x9369e7a3 +[NSSound _searchForSoundNamed:] + 626
    > 3 com.apple.AppKit 0x9369e8a5 +[NSSound soundNamed:] + 203
    > 4 org.m0k.transmission 0x00010829 -[PrefsController sounds] + 339
    [snip]

    A quick read of the documentation for +[NSSound soundNamed:] show
    that it returns an NSSound object with name, creating it if the sound
    is not already "known" and can be found. The docs detail the method
    it uses to search for the sound. That and the backtrace you included
    would indicate that the sound you're attempting to access is not
    known, with the crash occurring when loading the sound data from the
    file. Perhaps there is something about the data in the sound file
    that NSSound doesn't like?

    - Mike
  • That's what I thought, but is there any way to check if the sound is valid without it crashing?

    -Mitch

    On Wednesday, October 24, 2007, at 01:48PM, "Michael Babin" <mbabin...> wrote:
    >
    > On Oct 24, 2007, at 12:07 PM, Mitchell Livingston wrote:
    >
    >> Some users are reporting crashes when using this with custom sounds
    >> in one of the directories.
    >>
    >> I'm a bit confused on how this could crash in soundNamed. A crash
    >> log is:
    >>
    >> Thread 0 Crashed:
    >> 0 com.apple.AppKit 0x93436ae4 -[NSSound _postInitialization] + 749
    >> 1 com.apple.AppKit 0x9369d868 -[NSSound
    >> initWithContentsOfURL:byReference:] + 256
    >> 2 com.apple.AppKit 0x9369e7a3 +[NSSound _searchForSoundNamed:] + 626
    >> 3 com.apple.AppKit 0x9369e8a5 +[NSSound soundNamed:] + 203
    >> 4 org.m0k.transmission 0x00010829 -[PrefsController sounds] + 339
    > [snip]
    >
    > A quick read of the documentation for +[NSSound soundNamed:] show
    > that it returns an NSSound object with name, creating it if the sound
    > is not already "known" and can be found. The docs detail the method
    > it uses to search for the sound. That and the backtrace you included
    > would indicate that the sound you're attempting to access is not
    > known, with the crash occurring when loading the sound data from the
    > file. Perhaps there is something about the data in the sound file
    > that NSSound doesn't like?
    >
    > - Mike
    >
    >
    >
  • On 10/24/07, Mitchell Livingston <livings124...> wrote:
    > That's what I thought, but is there any way to check if the sound is valid without it crashing?

    It shouldn't crash regardless of the junk you (or customers) may feed
    it. You should file a bug with a sound file that triggers it
    (http://developer.apple.com/bugreporter/).

    You may have to side step using NSSound and use Core Audio (possibly
    via QuickTime for some formats) directly assuming you cannot ensure
    you have a sound file that doesn't trigger this crash.

    -Shawn
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today