Okay, I can definitely recreate the bug and it is a nasty one that happens due to the sequence that closing an existing html toc flow tab uses.
The good news, is that there are easy workarounds:
1. Manually close the html toc file CodeView Tab (assuming it is the one that is properly marked in the guide via the "toc" semantics) before firing up Tools->Table Of Contents ->Create HTML Table of Contents
or
2. Disable the guide semantics for "toc" on the html toc file by right clicking on it in the browser and use Add Semantics and reselecting the "Table of Contents" which should toggle it off (or manually edit the guide section of the opf to do the same). This will force Sigil to create a completely new file to house the created html toc.
Here is the backtrace which shows what is going on:
Code:
lldb back trace of crash
bt
* thread #1: tid = 0x6263f, 0x00000001037736dd QtGui`QTextCursor::QTextCursor(QTextCursor const&) + 13, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00000001037736dd QtGui`QTextCursor::QTextCursor(QTextCursor const&) + 13
frame #1: 0x0000000100cecdb6 QtWidgets`QWidgetTextControl::textCursor() const + 22
frame #2: 0x0000000100d07dd9 QtWidgets`QPlainTextEdit::textCursor() const + 25
frame #3: 0x00000001002f6db9 Sigil`CodeViewEditor::ExecuteCaretUpdate(bool) + 57
frame #4: 0x00000001000103fc Sigil`FlowTab::ResourceModified() + 44
frame #5: 0x0000000103dedb4c QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3020
frame #6: 0x0000000103dedb4c QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3020
frame #7: 0x0000000103745f39 QtGui`___lldb_unnamed_symbol1777$$QtGui + 1049
frame #8: 0x000000010378fb41 QtGui`QSyntaxHighlighter::setDocument(QTextDocument*) + 273
frame #9: 0x000000010378fcea QtGui`QSyntaxHighlighter::~QSyntaxHighlighter() + 26
frame #10: 0x00000001001ec44d Sigil`XHTMLHighlighter::~XHTMLHighlighter() + 125
frame #11: 0x0000000103de563d QtCore`QObjectPrivate::deleteChildren() + 221
frame #12: 0x0000000100b48e62 QtWidgets`QWidget::~QWidget() + 1458
frame #13: 0x00000001002e444e Sigil`CodeViewEditor::~CodeViewEditor() + 14
frame #14: 0x000000010000f808 Sigil`FlowTab::~FlowTab() + 120
frame #15: 0x000000010000f8de Sigil`FlowTab::~FlowTab() + 14
frame #16: 0x0000000103de60f0 QtCore`QObject::event(QEvent*) + 896
frame #17: 0x0000000100b5a589 QtWidgets`QWidget::event(QEvent*) + 5593
In Create HTML TOC we look in the guide for an existing html toc. If it exists and if it is in an open tab in CodeView we try to close it. This leads to the FlowTab destructor to be called which tries to close the CodeView editor it is attached to which tries to close the XHTMLSyntax Highlighter which in turn tries to close the Qt internal QSyntaxHighlighter but for some reason in its destructor it tries to load the underlying TextDocument and that creates a signal to the Resource that it has been changed and that in turn tries to update its CodeView tab (the one we were trying to close) eventually causing the segfault.
I have no idea why the QSyntaxHighlighter would write to QTextDocument in its DESTRUCTOR! This seems like a real Qt bug. I will try to figure out how to temporarily stop the signal for contents changing when in the destructor.
What a mess! Nice test case in that it clearly showed the issue as long as I had the previous html toc open in a CodeView Tab when I tried to rebuild it.