Re: CFSocket crash in Jaguar [solved]
Re: CFSocket crash in Jaguar [solved]
- Subject: Re: CFSocket crash in Jaguar [solved]
- From: Dave Camp <email@hidden>
- Date: Tue, 4 May 2004 19:42:37 -0700
Turns out my problem was due to a stray call to free() that was freeing
a stack variable. It took three separate code inspections with two
other engineers before we found that. Our code seem to work just fine
on Jaguar now.
Thanks!
Dave
On May 3, 2004, at 4:01 PM, Quinn wrote:
At 13:08 -0700 3/5/04, Dave Camp wrote:
Any suggestions for figuring out what CFSocket is doing or what
function pointer it's using is bad?
Take a look at these two data points.
Thread 2 Crashed:
#0 0x00000000 in 0x0
#1 0x90162b38 in __CFSocketPerform
PPC Thread State:
srr0: 0x00000000 srr1: 0x4000d030 vrsave: 0x00000000
xer: 0x20000000 lr: 0x9013ee30 ctr: 0x00000000 mq: 0x00000000
Note how LR (the register that PPC copies the return address to during
a function call) is 0x9013ee30, and yet the backtrace doesn't show
that address. It seems that CrashCatcher has skipped a frame in the
backtrace, which is a little confusing.
However, if you fire up GDB...
[mr-hoots:~] quinn% gdb
attach to any app...
(gdb) attach Finder
and disassemble __CFSocketPerform...
(gdb) x/8i 0x90162b38-4
0x90162b34 <__CFSocketPerform+612>: bl 0x9013ed9c
<CFDataGetLength>
you'll see that it looks like a call to CFDataGetLength. Then, if you
disassemble, the LR value...
(gdb) x/8i 0x9013ee30-4
0x9013ee2c <CFDataGetLength+144>: bctrl
you'll see that it is in fact in CFDataGetLength. The weird thing is,
why would CFDataGetLength call a function pointer?
The answer relates to CF-to-Cocoa toll-free bridging. If you call
CFDataGetLength on a Cocoa object that's a subclass of NSData, it has
to do the right thing (that is, call the subclass's "length" method).
If you look at the code (which is in Darwin btw)...
<http://www.opensource.apple.com/darwinsource/10.3.3/CF-299.3/
Collections.subproj/CFData.c>
[This link requires an APSL <http://www.opensource.apple.com/apsl/>
account.]
you'll see that it starts with code like this...
CF_OBJC_FUNCDISPATCH0(__kCFDataTypeID, CFIndex, data, "length");
I take it you don't have any Objective-C in your program? Which leads
me to think that CF is confused when it tries to dispatch to an
Objective-C subclass. To understand why, you have to look inside
CF_OBJC_FUNCDISPATCH0. Again, this is in Darwin...
<http://www.opensource.apple.com/darwinsource/10.3.3/CF-299.3/
Base.subproj/CFInternal.h>
CF_OBJC_FUNCDISPATCH0 relies on an inline function, CF_IS_OBJC, to
determine whether the CF object is actually a Cocoa object. My
experience is that when you get crashes like this, it's because this
function is returning true for a standard CF object.
This function makes its determination based on the _isa field of the
CF object, which is basically a pointer to the object's class data
structure. This field makes up the first field of the CF object.
Again, you can see this in Darwin...
<http://www.opensource.apple.com/darwinsource/10.3.3/CF-299.3/
Base.subproj/CFRuntime.h>
So, if the first word of the object is corrupt, CF thinks it's an
Objective-C object, and calls a bogus function pointer.
The upshot of this is that you probably have a memory corruption
problem. I'd recommend running your program with the usual tools
(MallocDebug, MallocScribble) to see if that flushes it out.
Of course, this doesn't guarantee that it's not a CFSocket problem;
there's just a lot more debugging to go between here and that
conclusion.
S+E
--
Quinn "The Eskimo!"
<http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications,
Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
---
It's not denial. I'm just very particular about the reality I choose to
accept. -Calvin
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.