On Feb 6, 2009, at 5:01 AM, Jesse Grosjean wrote:
With Bill's help I've found at least one cause of the garbage
collection is ON NSCFDictionary crash. If anyone else has a garbage
collected app that crashes frequently on startup with the crash
described above check for the p
With Bill's help I've found at least one cause of the garbage
collection is ON NSCFDictionary crash. If anyone else has a garbage
collected app that crashes frequently on startup with the crash
described above check for the presence of:
/Library/QuickTime/Sonix SN9C102p
WebCam.componen
On 2/3/09 12:31 PM, Greg Parker said:
>
>On Feb 3, 2009, at 9:30 AM, Sean McBride wrote:
>
>> On 2/3/09 7:48 AM, Bill Bumgarner said:
>>
>>> Exception Codes: KERN_INVALID_ADDRESS at 0xa1b1c1d8
>>>
>>> That seems like a rather suspicious address. a1b1c1d8? Fishy.
>>
>> I saw an a1b1c1
On Feb 3, 2009, at 9:30 AM, Sean McBride wrote:
On 2/3/09 7:48 AM, Bill Bumgarner said:
Exception Codes: KERN_INVALID_ADDRESS at 0xa1b1c1d8
That seems like a rather suspicious address. a1b1c1d8? Fishy.
I saw an a1b1c1d1+ crash the other day (also a GC app),
and thought I
>>> Are you creating any CFDictionaries that have any of the atypical storage
>>> patterns?
Not that I can find, I can't find any CFMutableDictionary or
CFDictionary references anywhere in my code.
> Do you have a software update mechanism that checks every now and then?
>
>Ahh... it appe
> GC support in Sparkle is pretty new, and I remember seeing some GC-
> related bugs last time I browsed the source. Jesse, are you using
> recent Sparkle code?
I am using the GC supported version of Sparkle, but I haven't updated
for a month or so. I'll look into that. Thanks. Jesse
On 2/3/09 9:23 AM, Bill Bumgarner said:
> Ahh... it appears that you do. Sparkle. Cool -- but -- it
>periodically checks for updates? Can you put a local copy of your
>app in a mode where it checks often and see what happens?
GC support in Sparkle is pretty new, and I remember seeing so
On 2/3/09 7:48 AM, Bill Bumgarner said:
> Exception Codes: KERN_INVALID_ADDRESS at 0xa1b1c1d8
>
>That seems like a rather suspicious address. a1b1c1d8? Fishy.
I saw an a1b1c1d1+ crash the other day (also a GC app),
and thought I remembered that number from the Debugging Magic tech
(Cc'ing the list w/the OP's permission)
On Feb 3, 2009, at 8:25 AM, Jesse Grosjean wrote:
If you can reproduce the crash at all, run your app with
MallocStackLoggingNoCompact set and then use malloc_history to find
out who
allocated the object.
However
Does the crash always include:
On Feb 3, 2009, at 7:16 AM, Jesse Grosjean wrote:
The crash is always in Thread1 and NSCFDictionary is always printed
near the top of the crash report. Does anyone have any idea of what
could be causing this. Or can you suggest some steps that I could take
to track it down?
If you can reproduce
I'm looking for some advice on tracking down a crash that I keep
getting reports about, but that I haven't reproduced locally. I have a
garbage collected app, and I keep getting (maybe 2 or 3 a day) the
following crash report:
---
11 matches
Mail list logo