Crashes related to garbage collection?

  • Hello list.

    At every startup my application checks the crash logs to see if there is a
    new crash log and if so sends it to me. I noticed that there are two classes
    of crash logs that seem to be related to garbage collection and I hope
    someone on the list is able to help me solve this crashes. Could they be the
    result of not holding on to objects with a strong reference?

    At the moment I have no idea how to reproduce them.

    --------------------------

    Crash Log 1

    --------------------------

    I have several crash logs similar to this. They always have the line
    starting test_node_integrity at the top of the log and the crashed thread
    always has a similar backtrace. What does test_node_integrity mean?

    Application Specific Information:

    objc[85244]: garbage collection is ON

    test_node_integrity:  FreeListNode 0x1245e20 { _prev = 0x0, _next =
    0x1245830, _size = 144 } failed integrity check.

    Thread 7 Crashed:

    0  libauto.dylib                  0x9360b6f8
    Auto::Admin::test_node_integrity(Auto::FreeListNode*) + 392

    1  libauto.dylib                  0x9360c050
    Auto::Admin::find_allocation(unsigned long, unsigned int, bool, bool&) + 136

    2  libauto.dylib                  0x9360f264
    Auto::Region::allocate(unsigned long, unsigned int, bool, bool) + 96

    3  libauto.dylib                  0x936108e4
    Auto::Zone::allocate_small_medium(unsigned long, unsigned int, bool, bool) +
    68

    4  libauto.dylib                  0x93601218 auto_zone_allocate_object + 84

    5  com.apple.CoreFoundation      0x9451dd00 _CFArrayReplaceValues + 2088

    6  com.apple.CoreFoundation      0x9451e868 CFArrayAppendValue + 224

    7  com.apple.CoreFoundation      0x9453a060
    _CFBundleCopyDirectoryContentsAtPath + 836

    8  com.apple.CoreFoundation      0x9453ad28 _CFSearchBundleDirectory + 128

    9  com.apple.CoreFoundation      0x9453b0d8 _CFFindBundleResourcesInRawDir
    + 136

    10  com.apple.CoreFoundation      0x9453b72c
    _CFFindBundleResourcesInResourcesDir + 680

    11  com.apple.CoreFoundation      0x9453ba94 _CFFindBundleResources + 808

    12  com.apple.CoreFoundation      0x9453bcd4
    CFBundleCopyResourceURLForLocalization + 172

    13  com.apple.LaunchServices      0x94668c34 _LSCopyBundleStringsForLocale
    + 44

    14  com.apple.LaunchServices      0x94668bd8
    _LSCopyBundleStringsForPreferredLocale + 132

    15  com.apple.LaunchServices      0x94669cf0 _LSBundleCopyLocalizedName +
    180

    16  com.apple.LaunchServices      0x94667898
    _LSCopyNodeAttribute_DisplayNameIfDifferentFromFSName(LSNodeAttributeStateCache*)
    + 88

    17  com.apple.LaunchServices      0x9466695c _LSCopyNodeAttribute + 108

    18  com.apple.LaunchServices      0x946668b0
    _LSCopyItemAttributeForRefInfoWithOptions + 220

    19  com.apple.DesktopServices      0x95bc92cc
    LockLSCopyItemAttributeForRefInfo(LSExtendedFSRefInfo const*, unsigned long,
    __CFString const*, void const**) + 72

    20  com.apple.DesktopServices      0x95bc91f0
    THFSPlusRef::GetDistinctDisplayName(unsigned long, FSCatalogInfo*,
    HFSUniStr255&) const + 164

    21  com.apple.DesktopServices      0x95bc90fc
    THFSPlusRef::SetDisplayName(unsigned long, FSCatalogInfo&) + 60

    22  com.apple.DesktopServices      0x95bc8774 THFSPlusRef::Set(FSRef const&,
    HFSUniStr255 const*, short, unsigned long, bool, unsigned long,
    FSCatalogInfo*) + 1500

    23  com.apple.DesktopServices      0x95c34c84
    THFSPlusIterator::NextSingle(THFSPlusRef&) + 148

    24  com.apple.DesktopServices      0x95be587c
    THFSPlusIterator::Next(THFSPlusRef&) + 56

    25  com.apple.DesktopServices      0x95c300c8
    THFSPlusSynchronizer::THFSPlusSynchronizer(THFSPlusRef const&) + 152

    26  com.apple.DesktopServices      0x95be5614
    TNode::SynchronizeChildren(bool) + 60

    27  com.apple.DesktopServices      0x95be4bf0 TNode::ReconcileChildren(bool,
    bool) + 112

    28  com.apple.DesktopServices      0x95be0fd8 TNode::HandleSync(bool, bool,
    bool, bool) + 368

    29  com.apple.DesktopServices      0x95be8884
    TNodeSyncTask::HandleInternalSync(TCountedPtr<TNodeEvent> const&, TNodePtr
    const&) + 180

    30  com.apple.DesktopServices      0x95bd2f84
    TNodeSyncTask::HandleInternalEvent(TCountedPtr<TNodeEvent> const&) + 264

    31  com.apple.DesktopServices      0x95bd2938
    TNodeSyncTask::SyncTaskProc(void*) + 168

    32  ...ple.CoreServices.CarbonCore 0x91ad3fc4 PrivateMPEntryPoint + 76

    33  libSystem.B.dylib              0x93328b98 _pthread_start + 316

    --------------------------

    Crash Log 2

    --------------------------

    Crash logs similar to this one always have a collection object directly
    after the gc line. I have seen NSCFDictionary, NSCFArray and NSCFSet.

    Exception Type:  EXC_BAD_ACCESS (SIGBUS)

    Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005

    Crashed Thread:  1

    Application Specific Information:

    objc[55222]: garbage collection is ON

    NSCFDictionary

    Thread 1 Crashed:

    0  com.apple.CoreFoundation      0x94981d10 __CFTypeCollectionRelease + 80

    1  com.apple.CoreFoundation      0x9494ec69 __CFDictionaryDeallocate + 281

    2  com.apple.Foundation          0x946b3721 -[NSCFDictionary finalize] +
    49

    3  libobjc.A.dylib                0x92d12976 finalizeOneObject + 56

    4  libauto.dylib                  0x950afdab
    foreach_block_do(auto_zone_cursor*, void (*)(void*, void*), void*) + 123

    5  libobjc.A.dylib                0x92d12b3b batchFinalize + 220

    6  libobjc.A.dylib                0x92d12e02 batchFinalizeOnTwoThreads + 98

    7  libauto.dylib                  0x950b0f0e
    auto_collect_internal(Auto::Zone*, int) + 782

    8  libauto.dylib                  0x950b1b8f auto_collection_thread(void*)
    + 111

    9  libSystem.B.dylib              0x93fb5c55 _pthread_start + 321

    10  libSystem.B.dylib              0x93fb5b12 thread_start + 34

    Best regards,

    Markus Müller
  • On May 26, 2008, at 08:17, Markus Müller wrote:

    > At every startup my application checks the crash logs to see if
    > there is a
    > new crash log and if so sends it to me. I noticed that there are two
    > classes
    > of crash logs that seem to be related to garbage collection and I hope
    > someone on the list is able to help me solve this crashes. Could
    > they be the
    > result of not holding on to objects with a strong reference?

    Both of these look like the crashes you frequently get using Open
    (NSOpenPanel) dialogs in a GC app. It's a known problem, with no known
    workaround that I've seen (although someone did suggest that throwing
    away the app's preferences file might reduce the frequency of the
    crashes for a while).
  • On May 26, 2008, at 9:57 AM, Quincey Morris wrote:
    > Both of these look like the crashes you frequently get using Open
    > (NSOpenPanel) dialogs in a GC app. It's a known problem, with no
    > known workaround that I've seen (although someone did suggest that
    > throwing away the app's preferences file might reduce the frequency
    > of the crashes for a while).

    The media browser in the open panel has a tendency to blow up GC'd
    apps.  Unfortunately, if you select the media browser in any
    application, it will be the default selected item in the open panel in
    all applications.

    You should be able to workaround it by nuking the related preference
    item.

    b.bum
  • Please excuse me for taking so long to get back to this thread!

    Thank you both for your answers. It's interesting that you think that those
    crashes are related to the open panel. I also have several crash logs that
    contain traces of open/save panel methode calls. If this doesn't get better
    in 10.5.3 I will consider rewriting my application to run in GC unsupported
    mode.

    Regards,

    Markus M.

    On Mon, May 26, 2008 at 10:47 PM, Bill Bumgarner <bbum...> wrote:

    > On May 26, 2008, at 9:57 AM, Quincey Morris wrote:
    >
    >> Both of these look like the crashes you frequently get using Open
    >> (NSOpenPanel) dialogs in a GC app. It's a known problem, with no known
    >> workaround that I've seen (although someone did suggest that throwing away
    >> the app's preferences file might reduce the frequency of the crashes for a
    >> while).
    >>
    >
    > The media browser in the open panel has a tendency to blow up GC'd apps.
    > Unfortunately, if you select the media browser in any application, it will
    > be the default selected item in the open panel in all applications.
    >
    > You should be able to workaround it by nuking the related preference item.
    >
    > b.bum
    >
previous month may 2008 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