Re: Crash in Carbon App quitting while AppleTalking
Re: Crash in Carbon App quitting while AppleTalking
- Subject: Re: Crash in Carbon App quitting while AppleTalking
- From: Quinn <email@hidden>
- Date: Tue, 11 Jun 2002 21:56:56 +0100
I don't actually have a solution to your problem, but I figured you
would appreciate the followintg info.
At 10:25 -0400 11/6/02, Lyndsey Ferguson wrote:
it could be the problem. From what I have read (from other people's emails)
of the crash report (is there any solid documentation on crash logs??), if
one of the threads does not begin with "mach_..." or end with "_trap", it
could be the area responsible for the crash. Is this correct?
That's a pretty good rule of thumb. In general, threads that are
running in routines like mach_msg_overwrite_trap are blocked waiting
for some sort of event. Thus, as a rule, they aren't responsible for
an exception crash (although they're prime suspects when debugging
deadlocks).
If so, the crash report (included below) seems to indicate either the call
"AsyncRegisterNameRequest" or "syscall" could be where the crash is
occurring. When I did a search for the AsyncRegisterNameRequest on Apple's
Dev site, google and groups.google.com I had no success finding any
information about such a call. I'm guessing that it is called from
OTRegisterName? Can someone tell me what it is?
AsyncRegisterNameRequest is an internal function to OT.framework; as
you theorise, it's used by OTRegisterName.
It appears that my attempt at OTCloseOpenTransportInContext is successful,
No, I disagree with that. The backtrace for Thread 5 in your crash
reporter log indicates that one of your threads is still in the
middle of calling CloseOpenTransportInContext.
before which I am telling my providers to:
- stop using sync idle events,
- remove their Notifier's
- set themselves to non blocking so I can close immediately
And
- close
If my application is crashing in OTRegisterName, how can I cancel the call
to OTRegisterName so it can get out before OTCloseOpenTransportInContext? Or
should I just be setting a flag that I can examine so that I wait until
OTRegisterName is done?
As a rule it's a bad idea to call OTCloseOpenTransportInContext while
a thread is still executing inside OT. Thus it's in your interests
to unblock your thread that's still inside OTRegisterName. You might
try calling OTCanclSynchronousCalls, which is supposed to do the
tricky.
Also, for future crash log reports can someone help me read/understand them?
My explanation is below.
Are there some tutorials or instructions for reading a crash report?
Not exactly. There are a couple of technotes on GDB that you might
find interestintg.
<
http://developer.apple.com/technotes/tn/tn2032.html>
<
http://developer.apple.com/technotes/tn/tn2030.html>
Ultimately, debugging crashes like this requires you to understand
how the OS works, and that's knowledge that's hard to come by if you
consistently work at a high-level in the OS.
I understand that somehow I can use the hex offsets to find where in my code
these calls are being made, is there documentation on that?
Crash reporter should show you whatever symbols that are in your
application. If the symbols aren't shown, it's because they're not
there. If you're coding Mach-O, make sure you turn on GDB symbols
(-g on the command line, don't know how to do this for PB). If
you're coding CFM, make sure you turn on traceback tables.
My explanation of crash reporter follows...
Date/Time: 2002-06-04 09:41:55 -0400
OS Version: 10.1.4 (Build 5Q125)
This stuff is pretty obvious.
Command: TheApplication
The name of the program that crashed. By the look of this it seems
that your program is a Mach-O application, so you should turn on GDB
symbols and things will get clearer.
PID: 326
The process ID of the program that crashed.
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x04a15598
The Mach exception code that caused the crash. The exceptions, and a
rough explanation for each, are given in <mach/exception_types.h>.
In this case the exception indicates that something accessed an
invalid memory address. Moreover, the invalid address that was
accessed was 0x04a15598. It's always worthwhile examining that
address for specific bad data (like ASCII) but in this case there's
nothing obvious.
I've brought the following entry forward from the end just because it
made it easier to explain things....
PPC Thread State:
srr0: 0x7055e494 srr1: 0x0000f030 vrsave: 0x00000000
xer: 0x00000004 lr: 0x7055e460 ctr: 0x7000a600 mq: 0x00000000
r0: 0x00000002 r1: 0x04b17d80 r2: 0x04b17d53 r3: 0x00000000
r4: 0x00000000 r5: 0x04b17cf0 r6: 0x00000000 r7: 0x00000000
r8: 0x00000000 r9: 0x54485244 r10: 0x00000000 r11: 0x80550358
r12: 0x7000a600 r13: 0x00000000 r14: 0x00000033 r15: 0x0005a040
r16: 0x00000001 r17: 0x80160fa8 r18: 0x0005f9d8 r19: 0x00001907
r20: 0x00000000 r21: 0x0000001c r22: 0x70004234 r23: 0x700042c8
r24: 0x7016b0dc r25: 0x006bac3c r26: 0x8081ab5c r27: 0xc0cc2000
r28: 0x00000000 r29: 0xbfffef00 r30: 0x87859393 r31: 0x00000001
This is a dump of the PowerPC registers at the time of the crash.
This doesn't really help you much, except to note that srr0 contains
the PC at the time of the crash. If you search forward through the
code you'll note that this value is the topmost PC in the backtrace
for Thread 3. It's also helpful to try to correlate register
contents with the invalid address that caused the exception, although
in this case there isn't an obvious correlation.
So, what you know from this is that Thread 3, at PC 0x7055e494, died
trying to access memory address 0x04a15598. It's not a lot but it's
a start.
Now we'll look at each of the threads in your app.
Thread 0:
#0 0x70000978 in mach_msg_overwrite_trap
#1 0x7024a0f0 in SwitchContexts
#2 0x702c9eec in YieldToThread
#3 0x005f262c in 0x5f262c
#4 0x005f2e78 in 0x5f2e78
#5 0x005f2560 in 0x5f2560
#6 0x005f22b0 in 0x5f22b0
#7 0x01288640 in 0x1288640
#8 0x01289480 in 0x1289480
Thread 0 is a cooperative thread (probably the main thread because
there's no CooperativeThread symbol listed in the backtrace) blocked
inside a YieldToAnyThread. Thread Manager uses a Mach message as a
token which it passes between the various cooperative threads to
allow them to run. The following technote gives a bit of details
about this.
<
http://developer.apple.com/technotes/tn/tn2028.html>
Thread 1:
#0 0x70000978 in mach_msg_overwrite_trap
#1 0x70005a04 in mach_msg
#2 0x7017bf98 in __CFRunLoopRun
#3 0x701b7100 in CFRunLoopRunSpecific
#4 0x7017b8e0 in CFRunLoopRunInMode
#5 0x7061be08 in NotificationThread__21XIOAudioDeviceManagerPB0
#6 0x706141c0 in Entry__9CAPThreadPB0
#7 0x7002054c in _pthread_body
Thread 1 is a thread created by the audio subsystem. Note the
mangled symbol IOAudioDeviceManager::NotificationThread. It's
blocked inside its CFRunLoop, so it's probably not hurting anyone.
Thread 2:
#0 0x7000497c in syscall
#1 0x70557600 in BSD_waitevent
#2 0x70554b80 in CarbonSelectThreadFunc
#3 0x7002054c in _pthread_body
Thread 2 is the thread that delivers asynchronous events to Open
Transport notifiers. OT.framework creates this thread to call select
("man select" for details) to allow it to simulate OT's asynchronous
events on BSD sockets, which is an essentially synchronous API.
Again, this thread is blocked so it's probably not a problem.
Thread 3:
#0 0x7055e494 in AsyncRegisterNameRequest
#1 0x705594f8 in CarbonOperationThreadFunc
#2 0x7002054c in _pthread_body
We already know that this is the thread that crashed. It's inside
CarbonOperationThreadFunc, which is an OT.framework routine that
actually executes asynchronous operations on behalf of OT clients
(similar to CarbonATOperThreadFunc, described below). In this case
the operation, AsyncRegisterNameRequest, is the code that does the
NBP registration.
Thread 4:
#0 0x70000978 in mach_msg_overwrite_trap
#1 0x70005a04 in mach_msg
#2 0x70026a2c in _pthread_become_available
#3 0x70026724 in pthread_exit
#4 0x7055f8b4 in CarbonATOperThreadFunc
#5 0x7002054c in _pthread_body
This thread is created by OT.framework to perform AppleTalk
operations (hence the function CarbonATOperThreadFunc). The thread
sits in an endless loop, getting the next operation, doing the
operation, and then looping waiting for the next operation. In this
case it looks like been given a message to quit (pthread_exit), and
is blocked doing some bookkeeping associated with the quit.
Thread 5:
#0 0x700343e8 in semaphore_wait_trap
#1 0x700342c8 in pthread_join
#2 0x7055b364 in CarbonCleanupLibThreads
#3 0x7055a7c4 in CarbonCleanOTInternals
#4 0x7055b2d0 in OTFreeClientContextPriv
#5 0x7055be4c in CloseOpenTransportInContext
#6 0x00583f64 in 0x583f64
#7 0x00582ff4 in 0x582ff4
#8 0x005f3834 in 0x5f3834
#9 0x7027ae58 in CooperativeThread
#10 0x7002054c in _pthread_body
This is your thread that's called CloseOpenTransportInContext. It's
blocked waiting for the threads that OT.framework spooled to quit
(CarbonCleanupLibThreads).
Thread 6:
#0 0x70044cf8 in semaphore_timedwait_signal_trap
#1 0x70044cd8 in semaphore_timedwait_signal
#2 0x7003f2b8 in _pthread_cond_wait
#3 0x70283ea4 in TSWaitOnConditionTimedRelative
#4 0x70270138 in MPWaitOnQueue
#5 0x70777cd8 in SyncTaskProc__13TNodeSyncTaskPv
#6 0x702831a8 in PrivateMPEntryPoint
#7 0x7002054c in _pthread_body
My guess is that this is an MP thread that you've created yourself
that's stuck waiting in a MPWaitOnQueue call inside your
TNodeSyncTask::SyncTaskProc method.
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.