Date
1 - 5 of 5
Care to opine on a stack trace
Sandor Szatmari
I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?
Thread 8 Crashed:
0 com.apple.CoreFoundation 0x9a462ce8 CFHash + 200
1 com.apple.CoreFoundation 0x9a465bc2 CFBasicHashFindBucket + 514
2 com.apple.CoreFoundation 0x9a46596b CFDictionaryGetValue + 123
3 com.apple.CoreFoundation 0x9a52fe82 _CFStreamUnscheduleFromRunLoop + 194
4 com.apple.CoreFoundation 0x9a59237d -[__NSCFInputStream removeFromRunLoop:forMode:] + 61
5 net.infoplus.downloader 0x00050544 -[ServerConnectionHandler handleNewServerConnection:] + 1038
6 com.apple.Foundation 0x9b0554d7 -[NSThread main] + 45
7 com.apple.Foundation 0x9b055262 __NSThread__start__ + 1550
8 libsystem_pthread.dylib 0x9bff9780 _pthread_body + 138
9 libsystem_pthread.dylib 0x9bff96f6 _pthread_start + 155
10 libsystem_pthread.dylib 0x9bff6f7a thread_start + 34
Sandor
Thread 8 Crashed:
0 com.apple.CoreFoundation 0x9a462ce8 CFHash + 200
1 com.apple.CoreFoundation 0x9a465bc2 CFBasicHashFindBucket + 514
2 com.apple.CoreFoundation 0x9a46596b CFDictionaryGetValue + 123
3 com.apple.CoreFoundation 0x9a52fe82 _CFStreamUnscheduleFromRunLoop + 194
4 com.apple.CoreFoundation 0x9a59237d -[__NSCFInputStream removeFromRunLoop:forMode:] + 61
5 net.infoplus.downloader 0x00050544 -[ServerConnectionHandler handleNewServerConnection:] + 1038
6 com.apple.Foundation 0x9b0554d7 -[NSThread main] + 45
7 com.apple.Foundation 0x9b055262 __NSThread__start__ + 1550
8 libsystem_pthread.dylib 0x9bff9780 _pthread_body + 138
9 libsystem_pthread.dylib 0x9bff96f6 _pthread_start + 155
10 libsystem_pthread.dylib 0x9bff6f7a thread_start + 34
Sandor
On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:Not exactly. In frame 4 the NSInputStream has been messaged successfully, which almost never happens if it’s already dealloced; you almost always get a crash in objc_msgsend in that case.
I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?
Instead it looks like something’s wrong with a dictionary managed by the stream. I don’t know exactly what.
What’s the offending memory address in the crash? If it’s zero, that could be a clue.
Can you run the app with NSZombie enabled until the crash reoccurs?
—Jens
Sandor Szatmari
Jens,
Thanks,
Sandor
On Mar 13, 2019, at 13:57, Jens Alfke <jens@...> wrote:Thanks for pointing out this out. That makes sense since presumably in the frames above we are in calls resulting from the stream removing itself which would be hard to explain if it were dealloc’d. Is this the right conclusion?On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:Not exactly. In frame 4 the NSInputStream has been messaged successfully, which almost never happens if it’s already dealloced; you almost always get a crash in objc_msgsend in that case.
I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?
Thanks for pointing me in a direction.
Instead it looks like something’s wrong with a dictionary managed by the stream. I don’t know exactly what.
I’m not experienced with putting these pieces together… can this be determined from the crash report? Or, do I need to determine this when a crash actually occurs?
What’s the offending memory address in the crash? If it’s zero, that could be a clue.
Can you run the app with NSZombie enabled until the crash reoccurs?I can and will…
Thanks,
Sandor
—Jens
On Mar 13, 2019, at 11:06 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:I’m not experienced with putting these pieces together… can this be determined from the crash report? Or, do I need to determine this when a crash actually occurs?
It’s in the crash report near the top, like this:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
That long hex number is the address.
—Jens
Sandor Szatmari
Jens,
Thanks here’s what I have,
On Mar 13, 2019, at 11:06 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:I’m not experienced with putting these pieces together… can this be determined from the crash report? Or, do I need to determine this when a crash actually occurs?It’s in the crash report near the top, like this:Exception Type: EXC_BAD_ACCESS (SIGSEGV)Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000That long hex number is the address.
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
*** CFHash() called with NULL ***
—Jens