On 9/29/12 3:40 PM, Ken Thomases wrote:
I sympathize. It can be very hard to debug these sorts of things.
A couple of things I would try:
1) Examine the registers for the stack frame of the objc_msgSend_vtable5()
call to see if you can figure out what message was being sent and possibly
its arguments.
<http://sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html>
Thanks Ken, I did go through all the posts there and while certainly
interesting, I'm not much wiser.
I tried finding out what object is being messaged (given the circumstance the
crash happens under, I don't think it could possibly be on of "my" objects
anyway), but I have not had a lot of luck.
I tried
(lldb) p/x $rdi
(unsigned long) $6 = 0x000000010a879e50
and then
(lldb) memory read 0x000000010a879e50
0x10a879e50: af 2b f1 11 00 00 00 10 00 00 00 00 00 00 00 50 .+.............P
0x10a879e60: 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
But that doesn't look like something I can draw any conclusions from.
2) Run under the Zombies instrument, which collects history for object
addresses. At the crash point, try to identify the address of the object
being messaged (see above) and then examine its history to figure what that
is/was, where it was allocated, and what might have happened to it. You can
also use MallocStackLoggingNoCompact to collect the history without the
Zombies instrument, if that's easier. Either use the malloc_history command
or gdb's "info malloc-history" command.
I tried the Zombies instrument but it just doesn't crash when it's being run
under Instruments. Instead Instruments eventually grinds to a halt eating up all
available memory.
I also got to know malloc-history, which is fantastic but I have a hard time
understanding how I could use it for the problem at hand. What I did is use p/x
$rdi to get the object being messaged and then filter malloc-history by that
address. I did that many times, and sometimes it produced result with few enough
allocations to actually being able to go through them and try to make sense of
it. It didn't help me in the end, but it's certainly interesting to have learned
a few new tricks.
You may have noticed I added [solved] to the subject. Yes, I managed to fix it,
and it was something completely different. I feel I owe the list a post-mortem,
so someone even less talented than myself may find it interesting to make sense
of a bug that doesn't make any sense.
When all attempts using tools failed, I started gutting the app, until I had a
reasonably small subset of code to look at. Its always good to know something is
NOT causing a problem. I isolated the problem into a view controller. After a
further hours going in the wrong direction I finally made the discovery:
I forgot to remove an observer from an array controller proxy keypath. I had
added
[ctrl addObserver:self forKeyPath:@"selectedObjects.someString"
options:NSKeyValueObservingOptionNew context:kSomeContext];
but never removed the observer. This caused the crash.
What I don't know is why the runtime didn't manage to warn me about it.
Something like "Object deallocated while still observing key path xxx" or
"Controller being deallocated while an observer is still registered". I saw
those a couple of times, maybe it's because I was observing a proxy?
Anyway, after hunting this damn thing for a couple of days exclusively, I'm
really relieved that it's fixed.
Thanks a lot to you an Kyle for the suggestions!
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
