Author Topic: BeachBallEdit?  (Read 3548 times)

os2bird

  • Senior Community Member
  • Posts: 114
  • Hero Points: 13
BeachBallEdit?
« on: December 14, 2012, 08:45:21 PM »
Hi!

I'm starting to get annoyed about SlickEdit hanging on the mac. Working on some python code now, it as locked up and put up the dreaded spinning beach ball several times the last hour. Since yesterday I am using 17.0.3.0, and either I'm just unlucky or the problem happens more frequently now. Earlier it used to lock up once every day or two, today it has happened a number of times already.

Not sure what exactly I'm doing to trigger this, I'm suspecting it has to do with jumping between python files or maybe symbol completion in python.  It usually happens when I have 2+ files containing unsaved changes.

Here is a stack walk from gdb of the hung vs process in case it is of any help:
Code: [Select]
(gdb) info threads
  8                                 0x00007fff9082ebca in __psynch_cvwait ()
  7                                 0x00007fff9082ebca in __psynch_cvwait ()
  6                                 0x00007fff9082ebca in __psynch_cvwait ()
  5                                 0x00007fff9082ebca in __psynch_cvwait ()
  4                                 0x00007fff9082ebca in __psynch_cvwait ()
  3                                 0x00007fff9082ee42 in __semwait_signal ()
  2 "com.apple.libdispatch-manager" 0x00007fff9082f7e6 in kevent ()
* 1 "com.apple.main-thread"         0x0000000101fe4ae0 in QAbstractItemDelegate::metaObject ()
(gdb) thread apply all bt

Thread 8 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b7bf in VSTHREADEVENT::wait ()
#3  0x0000000100b7cd3d in fileDateThread::run ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 7 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x00000001008947e6 in slickedit::SEListTagsThread::runAsWriter ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 6 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894ccf in slickedit::SEListTagsThread::runAsTagger ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 5 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894ccf in slickedit::SEListTagsThread::runAsTagger ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 4 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894f98 in slickedit::SEListTagsThread::runAsReader ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 3 (process 86085):
#0  0x00007fff9082ee42 in __semwait_signal ()
#1  0x00007fff96df6dea in nanosleep ()
#2  0x000000010093b12a in VSTHREAD::sleep ()
#3  0x000000010004049f in btFileCacheFillThread::run ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 2 (process 86085):
#0  0x00007fff9082f7e6 in kevent ()
#1  0x00007fff96f57786 in _dispatch_mgr_invoke ()
#2  0x00007fff96f56316 in _dispatch_mgr_thread ()

Thread 1 (process 86085):
#0  0x0000000101fe4ae0 in QAbstractItemDelegate::metaObject ()
#1  0x0000000101ee0a9b in QTreeWidget::invisibleRootItem ()
#2  0x00000001000dbf16 in vsCtlTreeView::getParent ()
#3  0x00000001000dbf4a in vsCtlTreeView::getDepth ()
#4  0x000000010023ab97 in p_treegetdepth_op ()
#5  0x0000000100206f74 in pmethod_op ()
#6  0x000000010005b472 in run_proc ()
#7  0x0000000100233393 in vs_call_key_new ()
#8  0x0000000100171191 in gui_edit_event_message ()
#9  0x00000001000efbda in vsCtlSlickCExecuteEvent ()
#10 0x00000001000f0174 in vsQTSlickCExecuteKeyEvent ()
#11 0x00000001019d71ad in QWidget::event ()
#12 0x0000000101d4efac in QFrame::event ()
#13 0x0000000101ddc57b in QAbstractScrollArea::event ()
#14 0x00000001000c4465 in vsCtlSlickCQAbstractScrollArea::event ()
#15 0x000000010197c15d in QApplicationPrivate::notify_helper ()
#16 0x0000000101983c5b in QApplication::notify ()
#17 0x000000010165d4dc in QCoreApplication::notifyInternal ()
#18 0x0000000100b5c983 in -[SlickEditApplication sendQtKeyPressEvent:withModifiers:] ()
#19 0x0000000100b5ce68 in -[SlickEditApplication handledKeyDownEvent:] ()
#20 0x0000000100b5c8b2 in -[SlickEditApplication sendEvent:] ()
#21 0x00007fff96181a0e in -[NSApplication run] ()
#22 0x0000000101937174 in QDesktopWidget::resizeEvent ()
#23 0x0000000101749a34 in QEventLoop::processEvents ()
#24 0x0000000101749d54 in QEventLoop::exec ()
#25 0x000000010174b37c in QCoreApplication::exec ()
#26 0x0000000100014e07 in vmain ()
#27 0x00000001009135f0 in xmain ()
#28 0x000000010002e9d9 in main ()
(gdb) c

Letting it run a little while:
Code: [Select]
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fff96e3f2e7 in __mtx_droplock ()
(gdb) thread apply all bt

Thread 8 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b7bf in VSTHREADEVENT::wait ()
#3  0x0000000100b7cd3d in fileDateThread::run ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 7 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x00000001008947e6 in slickedit::SEListTagsThread::runAsWriter ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 6 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894ccf in slickedit::SEListTagsThread::runAsTagger ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 5 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894ccf in slickedit::SEListTagsThread::runAsTagger ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 4 (process 86085):
#0  0x00007fff9082ebca in __psynch_cvwait ()
#1  0x00007fff96e44274 in _pthread_cond_wait ()
#2  0x000000010093b1e8 in VSTHREADEVENT::wait ()
#3  0x0000000100894f98 in slickedit::SEListTagsThread::runAsReader ()
#4  0x000000010093b580 in VSTHREAD::thread_proc ()
#5  0x00007fff96e408bf in _pthread_start ()
#6  0x00007fff96e43b75 in thread_start ()

Thread 2 (process 86085):
#0  0x00007fff9082f7e6 in kevent ()
#1  0x00007fff96f57786 in _dispatch_mgr_invoke ()
#2  0x00007fff96f56316 in _dispatch_mgr_thread ()

Thread 1 (process 86085):
#0  0x00007fff96e3f2e7 in __mtx_droplock ()
#1  0x00007fff96e3f6ab in pthread_mutex_unlock ()
#2  0x0000000100206282 in vsCheckWid2P ()
#3  0x000000010023a675 in vsTreeCurIndex ()
#4  0x000000010023a714 in p_treecurindex_op ()
#5  0x0000000100206f74 in pmethod_op ()
#6  0x000000010005b472 in run_proc ()
#7  0x0000000100233393 in vs_call_key_new ()
#8  0x0000000100171191 in gui_edit_event_message ()
#9  0x00000001000efbda in vsCtlSlickCExecuteEvent ()
#10 0x00000001000f0174 in vsQTSlickCExecuteKeyEvent ()
#11 0x00000001019d71ad in QWidget::event ()
#12 0x0000000101d4efac in QFrame::event ()
#13 0x0000000101ddc57b in QAbstractScrollArea::event ()
#14 0x00000001000c4465 in vsCtlSlickCQAbstractScrollArea::event ()
#15 0x000000010197c15d in QApplicationPrivate::notify_helper ()
#16 0x0000000101983c5b in QApplication::notify ()
#17 0x000000010165d4dc in QCoreApplication::notifyInternal ()
#18 0x0000000100b5c983 in -[SlickEditApplication sendQtKeyPressEvent:withModifiers:] ()
#19 0x0000000100b5ce68 in -[SlickEditApplication handledKeyDownEvent:] ()
#20 0x0000000100b5c8b2 in -[SlickEditApplication sendEvent:] ()
#21 0x00007fff96181a0e in -[NSApplication run] ()
#22 0x0000000101937174 in QDesktopWidget::resizeEvent ()
#23 0x0000000101749a34 in QEventLoop::processEvents ()
#24 0x0000000101749d54 in QEventLoop::exec ()
#25 0x000000010174b37c in QCoreApplication::exec ()
#26 0x0000000100014e07 in vmain ()
#27 0x00000001009135f0 in xmain ()
#28 0x000000010002e9d9 in main ()

Kind Regards,
 bird.

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: BeachBallEdit?
« Reply #1 on: December 17, 2012, 05:54:34 PM »
Do you have the Preview tool window and/or the Defs tool window visible? Those two windows both contain tree controls (where it looks like the hang is occurring), and both those windows update their contents when switching between buffers.

And while not related to the tree, where we have seen repeated hangs in the past is when project/workspace tag file cannot complete its tagging in the background. Usually this is due to some construct in the code that the tagging parser can't get past, thereby preventing the background tagging job from completing. The repeated attempts to rebuild that tag file can trigger this type of hang.

So, my recommended first step, if you're using a project, is to manually rebuild your project's tag file. Close all open code windows and then invoke the Project > Retag Workspace... menu command. Make sure the "Retag files is background" option is deselected so that the retagging progress can be seen in a modal progress dialog. If there's any code in the project tripping up the tagging parser, you'll be able to see what file is causing the hang.

If the tagging checks out OK, then the next step is to close the Defs and Preview tool windows to see if those are somehow the culprit(s). I use those tool windows all the time on the Mac, but they are 99% of the time in a minimized state, and not pinned to be always visible.

os2bird

  • Senior Community Member
  • Posts: 114
  • Hero Points: 13
Re: BeachBallEdit?
« Reply #2 on: December 17, 2012, 06:45:42 PM »
Yes, I had the Previews tab open but not visible. No Defs tab open. Attaching a screen shot showing which tabs I have enabled and which were visible when having the troubles the other day.

Regarding the tag file, I regenerated the workspace and tag file from scratch when updating the editor earlier in the evening (*).  So, I guess that leaves the python code I was refactoring at the time. I was (manually) refactoring method calls and such in several files, having (unsaved) syntactically incorrect code in one or two. At least one of hangs happened while walking references to a method call I was changing.

Btw. it seems I must've been unlucky last week, it only locked up once or twice since then (and I've been working most of the weekend). So, no 17.0.3.0 regression, I think.

Thanks for the advice,
 -bird.

(*) I'm sure I did a retag in the foreground like you suggested actually, because background tagging a workspace with 21500 files takes forever and day. To be quite honest, the threaded tagging feature is still a major PITA and performs horribly. It causes ~30 sec lockup relatively frequently, esp. if the "Update workspace tag file on activate" option is enabled and testing/building/debugging requires frequent activity in a different application (terminal, debugger, browser, irc, etc).

os2bird

  • Senior Community Member
  • Posts: 114
  • Hero Points: 13
Re: BeachBallEdit?
« Reply #3 on: December 19, 2012, 12:36:33 AM »
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

Code: [Select]
(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