Re: CFSocket crash in Jaguar
Re: CFSocket crash in Jaguar
- Subject: Re: CFSocket crash in Jaguar
- From: Quinn <email@hidden>
- Date: Tue, 4 May 2004 00:01:35 +0100
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.