Active Thread
This pattern was introduced in Accelerated Mac OS X Core Dump Analysis24 training. Basically it is a thread that is not waiting or suspended (most threads are). However, from a memory dump it is not possible to find out whether it was spiking (Volume 1, page 305) at the dump generation time (unless we have a set of memory snapshots and in each one we have the same or similar back trace) and we don't have any paratext (page 225) with CPU consumption stats for threads. For example, in one core dump we have these threads:
(gdb) info threads 12 0x98c450ee in __workq_kernreturn () 11 0x98c4280e in semaphore_wait_trap () 10 0x98c448e2 in __psynch_cvwait () 9 0×00110171 in std::_Rb_tree<int, std::pair<int const, _iCapture*>, std::_Select1st<std::pair<int const, _iCapture*> >, std::less<int>, std::allocator<std::pair<int const, _iCapture*> > >::find () 8 0×98c428e6 in mach_wait_until () 7 0×98c448e2 in __psynch_cvwait () 6 0×98c427d2 in mach_msg_trap () 5 0×98c427d2 in mach_msg_trap () 4 0×98c428e6 in mach_wait_until () 3 0×98c427d2 in mach_msg_trap () 2 0×98c459ae in kevent () * 1 0×014bcee0 in cgGLGetLatestProfile ()
Threads #9 and #1 are not waiting so we inspect their back traces:
(gdb) bt #0 0x014bcee0 in cgGLGetLatestProfile () #1 0x99060dd5 in exit () #2 0x001ef859 in os_exit () #3 0x001dc873 in luaD_precall () #4 0x001e7d9e in luaV_execute () #5 0x001dc18b in luaD_rawrunprotected () #6 0x001dced4 in lua_resume () #7 0x0058a526 in ticLuaManager::executeProgram () #8 0x005a09af in ticLuaScript::_execute () #9 0x003a6480 in darcScript::execute () #10 0x003af4d8 in darcTimeline::execute () #11 0x0034a2ba in darcSequenceur::executeAll () #12 0x0036904b in darcEventManager::ExecuteEventHandler () #13 0x003a37d2 in darcScene::process () #14 0x0034a2ba in darcSequenceur::executeAll () #15 0x0036904b in darcEventManager::ExecuteEventHandler () #16 0x00343ec0 in darcContext::process () #17 0x00347339 in darcContext::main () #18 0x003cf73d in darcPlayerImpl::renderOneFrame () #19 0x003cf078 in darcPlayerImpl::render () #20 0x000b1f6f in Run () #21 0x000b1fe9 in tiMain () #22 0x000c73ee in main ()
(gdb) thread 9 [Switching to thread 9 (core thread 8)] 0x00110171 in std::_Rb_tree<int, std::pair<int const, _iCapture*>, std::_Select1st<std::pair<int const, _iCapture*> >, std::less<int>, std::allocator<std::pair<int const, _iCapture*> > >::find ()
(gdb) bt #0 0x00110171 in std::_Rb_tree<int, std::pair<int const, _iCapture*>, std::_Select1st<std::pair<int const, _iCapture*> >, std::less<int>, std::allocator<std::pair<int const, _iCapture*> > >::find () #1 0x0010f936 in ticVideoManager::isPaused () #2 0x00201801 in ticMLT_VideoCapture::Execute () #3 0x0020aa0b in ticModuleGraph::runOnce () #4 0x002632be in TrackingApp::ProcessTracking () #5 0x005b2f5d in ticMLTTracking::processInternal () #6 0x005b322d in ticMLTTracking::processThread () #7 0x005b36f3 in trackingThread () #8 0x004eaf1e in ticThread::threadFunc () #9 0x99023557 in _pthread_start () #10 0x9900dcee in thread_start ()
Windows equivalent would be a process memory dump which doesn't have any information saved for !runaway WinDbg command.
24 http://www.patterndiagnostics.com/accelerated-macosx-core-dump-analysis-book