Re: NSTimer, no invalidate while shutting down?
Re: NSTimer, no invalidate while shutting down?
- Subject: Re: NSTimer, no invalidate while shutting down?
- From: Tom Harrington <email@hidden>
- Date: Sat, 24 Jan 2004 17:27:35 -0700
On Friday, January 23, 2004, at 08:24 PM, Nick Zitzmann wrote:
On Jan 23, 2004, at 11:38 AM, Tom Harrington wrote:
I use an NSTimer to periodically call a method. When the app is
exiting, its cleanup method includes calling [myTimer invalidate].
Normally this is fine and works as expected. But there's one
exception: If the app is running on Panther when the system is
shutting down, the call to -invalidate blocks and never seems to
return. Logged in remotely, I can also see that the app draws 90% of
CPU or more when this is happening. After 30 seconds or so the OS
apparently gives up and just destroys the process or something.
If you can, try running the program in GDB (the debugger) and
reproduce the problem, and then try pausing the program to see what
it's doing. That's the first thing I'd try in a situation like this...
Also, profiler output (from Shark, or Activity Monitor's sampler)
would be helpful.
I'm not sure how I can get profiler info, given that this bug (?) only
occurs when the OS is in the process of killing off all processes. But
I did manage to see where the program's hung up, by logging in remotely
and using GDB. It's not very enlightening, though, all it tells me is
that calling -[NSTimer invalidate] spins off into low-level stuff and
never returns. I might guess I had corrupted memory or stack or
something if not for the fact that this works fine under 10.1.x and
Jaguar in all cases, and in Panther in all cases except when the Mac is
shutting down.
Maybe the real question should be, is there any reason for me to
invalidate the NSTimer when I'm going to exit the process anyway, or
can I just forget about it? I was trying to do all the proper cleanup
steps when the object in question is released, but since the release
only happens at quit time, maybe I shouldn't bother being so careful
with the timer?
(gdb) where
#0 0x900075c8 in mach_msg_trap ()
#1 0x90007118 in mach_msg ()
#2 0x9001d588 in bootstrap_look_up ()
#3 0x96c3ad80 in WaitForServer(char const*) ()
#4 0x96c09dec in INIT_FontObjects(unsigned) ()
#5 0x96c09ca0 in FOLazyInitialize ()
#6 0x96c14e84 in _eFOCreateFontFamilyIterator ()
#7 0x96c14dd8 in FOCreateFontFamilyIterator ()
#8 0x9280c420 in GetScriptFontFlags ()
#9 0x92830f64 in InitializeScriptHL ()
#10 0x902887b0 in LMGetIntlSpec ()
#11 0x9028b388 in GetScriptManagerVariable ()
#12 0x9028e524 in GetIntlResource ()
#13 0x901ea1c8 in CFLocaleCopyCurrent ()
#14 0x90a13b68 in __NSLCCreateICUSettings ()
#15 0x90a512f8 in +[NSLanguageContext _resetAlternateICUValues] ()
#16 0x909f2334 in +[NSUserDefaults standardUserDefaults] ()
#17 0x90a1adb8 in +[NSBundle mainBundle] ()
#18 0x90a22fb8 in _timerRelease ()
#19 0x901a9b5c in CFRunLoopTimerInvalidate ()
#20 0x0000f07c in -[(deleted for email)] (self=0x308520, _cmd=0x14c84)
at (deleted for email).m:387
Line 20 is where I've tried to invalidate the timer. Below this in the
trace everything is normal for my signal handling code (responding in
this case to signal 15, TERM, which is what Mac OS X sends when it
wants the process to stop at shutdown time). I wasn't able to do any
stepping around after getting this trace because the OS kills off my
GDB session in order to shut down.
I tried sending a TERM signal to the process when the system wasn't
shutting down. With careful breakpoints I got as far as
INIT_FontObjects but never to WaitForServer. With "stepi" I saw a lot
of Mach message activity, mach_msg() and a lot of Mach port-related
functions.
--
Tom Harrington
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.