Hi again.
Slickedit went spinning the ball again, different scenario, just as annoying. It's tight-looping in LWMark::openReplace(), walking a circular list with one node in it. Was working on some C/C++ code this time, moving the cursor (not mouse, the other one) over "minor(Dev)" in the middle of the screen shot (see attachment). Below there are also some details from the debugger.
Enjoy :-)
- bird
(gdb) info threads
18 0x00007fff96e43b79 in start_wqthread ()
17 "CFMachPort" 0x00007fff9082d67a in mach_msg_trap ()
7 0x00007fff9082ebca in __psynch_cvwait ()
6 0x00007fff9082ebca in __psynch_cvwait ()
5 0x00007fff9082ebca in __psynch_cvwait ()
4 0x00007fff9082ebca in __psynch_cvwait ()
3 0x00007fff9082ebca in __psynch_cvwait ()
2 "com.apple.libdispatch-manager" 0x00007fff9082f7e6 in kevent ()
* 1 "com.apple.main-thread" 0x00000001001adee0 in LWMark::openReplace ()
(gdb) bt
#0 0x00000001001adee0 in LWMark::openReplace ()
#1 0x000000010024525b in hreplace_text_undo ()
#2 0x0000000100196f28 in hreplacelineb ()
#3 0x00000001001974fb in hTruncReplaceLineB ()
#4 0x00000001002231d9 in vsaReplaceLine ()
#5 0x00000001002234e1 in preplace_line_raw_op ()
#6 0x0000000100206f74 in pmethod_op ()
#7 0x000000010005b472 in run_proc ()
#8 0x000000010007d4d7 in run_proc_immediate2 ()
#9 0x000000010007d6e8 in run_callback_immediate ()
#10 0x000000010025a7c4 in se_call_callback ()
#11 0x00000001001859c7 in vs_execute_timer_event ()
#12 0x0000000101757c10 in QObject::event ()
#13 0x00000001019d683e in QWidget::event ()
#14 0x000000010197c15d in QApplicationPrivate::notify_helper ()
#15 0x000000010198218d in QApplication::notify ()
#16 0x000000010165d4dc in QCoreApplication::notifyInternal ()
#17 0x000000010197c1fc in QApplicationPrivate::notify_helper ()
#18 0x000000010193576c in QDesktopWidget::resizeEvent ()
#19 0x00007fff8d9d0934 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#20 0x00007fff8d9d0486 in __CFRunLoopDoTimer ()
#21 0x00007fff8d9b0e11 in __CFRunLoopRun ()
#22 0x00007fff8d9b0486 in CFRunLoopRunSpecific ()
#23 0x00007fff914482bf in RunCurrentEventLoopInMode ()
#24 0x00007fff9144f56d in ReceiveNextEventCommon ()
#25 0x00007fff9144f3fa in BlockUntilNextEventMatchingListInMode ()
#26 0x00007fff96185779 in _DPSNextEvent ()
#27 0x00007fff9618507d in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#28 0x00007fff961819b9 in -[NSApplication run] ()
#29 0x0000000101937174 in QDesktopWidget::resizeEvent ()
#30 0x0000000101749a34 in QEventLoop::processEvents ()
#31 0x0000000101749d54 in QEventLoop::exec ()
#32 0x000000010174b37c in QCoreApplication::exec ()
#33 0x0000000100014e07 in vmain ()
#34 0x00000001009135f0 in xmain ()
#35 0x000000010002e9d9 in main ()
**REMARK: This stack or slight variations of it (_ZN12StreamLWMark18isGroupIndicatorOnEv on top, slightly
**REMARK: different address), has been seen every time I broke into the debugger. One core is at 100% when
**REMARK: not in debugger. Smells like it's looping somewhere. Hopefully tight…
**REMARKS: Some stepping shows this section of code to be spinning tightly.
(gdb) x/9i $rip
0x1001adee0 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+848>: mov (%rbx),%rax
0x1001adee3 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+851>: mov %rbx,%rdi
0x1001adee6 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+854>: callq *0x20(%rax)
0x1001adee9 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+857>: test %al,%al
0x1001adeeb <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+859>: jne 0x1001adefc <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+876>
0x1001adeed <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+861>: mov 0x18(%rbx),%rbx
0x1001adef1 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+865>: cmp %rbx,-0x40(%rbp)
0x1001adef5 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+869>: jne 0x1001adee0 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+848>
0x1001adef7 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+871>: jmpq 0x1001adbce <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+62>
**REMARK: Step thru.
(gdb) x/i $rip
0x1001adee0 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+848>: mov (%rbx),%rax
(gdb) p/x $rbx
$4 = 0x12d1fcb10
(gdb) ni
0x00000001001adee3 in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adee3 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+851>: mov %rbx,%rdi
(gdb) ni
0x00000001001adee6 in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adee6 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+854>: callq *0x20(%rax)
(gdb) x/a $rax+0x20
0x10102ac70 <_ZTV12StreamLWMark+48>: 0x100249a90 <_ZN12StreamLWMark18isGroupIndicatorOnEv>
(gdb) ni
0x00000001001adee9 in LWMark::openReplace ()
(gdb) info reg
rax 0x0 0
rbx 0x12d1fcb10 5052025616
rcx 0x431e 17182
rdx 0x12d1f2a08 5051984392
rsi 0x1 1
rdi 0x12d1fcb10 5052025616
rbp 0x7fff5fbfcda0 0x7fff5fbfcda0
rsp 0x7fff5fbfcd00 0x7fff5fbfcd00
r8 0x7fff5fbfcc1c 140734799793180
r9 0x7fff5fbfcc18 140734799793176
r10 0x881 2177
r11 0x130207cfe 5102402814
r12 0x7fff5fbfcd50 140734799793488
r13 0x1d7 471
r14 0x1983 6531
r15 0x12d1fa120 5052014880
rip 0x1001adee9 0x1001adee9 <LWMark::openReplace(LWMReplaceInfo&, hfile_t*, int, int, long, long)+857>
eflags 0x246 582
cs 0x2b 43
ss 0x0 0
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
**REMARKS: The pointer that was called is a leaf method (make no calls) and it
**REMARKS: is const (doesn't change any data).
**REMARKS: It returned FALSE (0). The next test fails.
(gdb) x/i $rip
0x1001adee9 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+857>: test %al,%al
(gdb) ni
0x00000001001adeeb in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adeeb <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+859>: jne 0x1001adefc <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+876>
(gdb) ni
0x00000001001adeed in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adeed <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+861>: mov 0x18(%rbx),%rbx
**REMARKS: This looks like we're walking a chain. Let's see what the current and next pointers are.
(gdb) p/x $rbx
$5 = 0x12d1fcb10
(gdb) x/1a $rbx + 0x18
0x12d1fcb28: 0x12d1fcb10
(gdb) x/4a $rbx
0x12d1fcb10: 0x10102ac50 <_ZTV12StreamLWMark+16> 0x1d7
0x12d1fcb20: 0x22cc 0x12d1fcb10
**REMARKS: A StreamLWMark object, not very surprisingly. The next pointer is the same as the current!
(gdb) ni
0x00000001001adef1 in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adef1 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+865>: cmp %rbx,-0x40(%rbp)
(gdb) x/1a $rbp - 0x40
0x7fff5fbfcd60: 0x12d1fcb40
(gdb) p/x $rbx
$6 = 0x12d1fcb10
**REMARK: Comparing with some stack variable. Only the stack variable is not equal to $rbx and
**REMARK: from what I can tell, never will be. So, the JNE below is taken and we repeat the process.
(gdb) ni
0x00000001001adef5 in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adef5 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+869>: jne 0x1001adee0 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+848>
(gdb) ni
0x00000001001adee0 in LWMark::openReplace ()
(gdb) x/i $rip
0x1001adee0 <_ZN6LWMark11openReplaceER14LWMReplaceInfoP7hfile_tiill+848>: mov (%rbx),%rax
**REMARK: Out of curiosity, the -0x40(%rbp) value (0x12d1fcb40) points to another StreamLWMark
**REMARK: object. It is also pointing to itself:
(gdb) x/4a 0x12d1fcb40
0x12d1fcb40: 0x10102ac50 <_ZTV12StreamLWMark+16> 0x97
0x12d1fcb50: 0xb 0x12d1fcb40