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


 

On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

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?
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.

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,

On Mar 13, 2019, at 13:57, Jens Alfke <jens@mooseyard.com> wrote:



On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

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?
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.
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?


Instead it looks like something’s wrong with a dictionary managed by the stream. I don’t know exactly what.
Thanks for pointing me in a direction.


What’s the offending memory address in the crash? If it’s zero, that could be a clue.
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?

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,

On Mar 13, 2019, at 14:13, Jens Alfke <jens@...> wrote:



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.

Thanks here’s what I have,

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
*** CFHash() called with NULL ***


—Jens