RE: CFSocket crash in Jaguar
RE: CFSocket crash in Jaguar
- Subject: RE: CFSocket crash in Jaguar
- From: Kaza Sudheer <email@hidden>
- Date: Tue, 4 May 2004 09:21:25 +0530
HI All,
We have same crashes when working with CFSocket and using threads under
Jaguar.
If I simply use CFSocket we never had Crash and not use any threads (Because
some libraries are not thread safe under Jaguar).
And more over some times Crashreport generated is wrong.
To avoid these crashes, move yourself to Panther.
~Kaza~
-----Original Message-----
From: email@hidden
[
mailto:email@hidden]On Behalf Of Quinn
Sent: Tuesday, May 04, 2004 4:32 AM
To: macnetworkprog
Subject: Re: CFSocket crash in Jaguar
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.su
bproj/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/C
FInternal.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/C
FRuntime.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.
_______________________________________________
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.