MobileRead Forums - Repeated crash

MobileRead Forums (https://www.mobileread.com/forums/index.php)

- Sigil (https://www.mobileread.com/forums/forumdisplay.php?f=203)

- - Repeated crash (https://www.mobileread.com/forums/showthread.php?t=291920)

Good morning, I know how you guys are about Sigil crashing, and I admire your attitude. I have been working on a series of books from the same author, and I have discovered a consistent action that causes this dreaded occurrence. Unfortunately, I don't think you'll be able to reproduce it--I've experimented, and it appears to be a unique occurrence based on the cumulative actions up to that point.

Here's what is going on. I'm working on the book, and finally arrive at the point where I am ready to create the Table of Contents. I create the internal TOC, then I go to the TOC I already have in the file, and make a copy of it. (There's some formatting inside it that I want to retain.)

I then go to create an HTML TOC, and every time, Sigil crashes. I reopen the same file, create the HTML TOC with no problems, and go about my business.

With the most recent one, I saved it beforehand, then made a copy of the entire file by copying/pasting in my file manager, then tried to create the HTML TOC, and got the expected crash. So I do have a copy of the file exactly as it was before the crash. But unfortunately, opening that copy (actually a COPY of that COPY--so I can leave the original copy unmolested) and performing the same action doesn't cause a crash.

Not wanting to get in trouble with the copyright police, I'm not attaching it, of course. If there's anything else I can do to help you to track down this pesky little error, please let me know.

Now, on a completely unrelated topic, I'm wondering if there's any way the user can modify one of Sigil's INI files to add "Add Link" to the right-click context menu?

Thanks for all you folks do. If I were to say that I totally love Sigil, I'd only be making an understatement.

Quote:

Originally Posted by JustinThought (Post 3607141)

[...] I create the internal TOC, then I go to the TOC I already have in the file, and make a copy of it.

I then go to create an HTML TOC, and every time, Sigil crashes. I reopen the same file, create the HTML TOC with no problems, and go about my business.

I run across this same Create HTML Table of Contents crash quite often, but I can't figure out the rhyme or reason. Same symptoms too.

It seems like it only occurs after I have worked on the book for a while, and it always works perfectly fine after I reload the EPUB and recreate the TOC.

I've just gotten in the habit of saving the EPUB at all "major" revisions, so I usually lose zero work when the crash happens.

Windows 10 64-bit (although I think I recall this happening back in Windows 7 as well). And it has been happening for quite a while, so it isn't something that was introduced very recently.

I'll definitely try to pay much closer attention to this the next time I run across it.

Quote:

Originally Posted by JustinThought (Post 3607141)

Now, on a completely unrelated topic, I'm wondering if there's any way the user can modify one of Sigil's INI files to add "Add Link" to the right-click context menu?

While not exactly what you wanted:

Did you know that there is an Insert Link button:

Attachment 159846

Or you could go into Edit > Preferences > Keyboard Shortcut, and search for "Link":

Attachment 159847

Or you could also create a Clip:

Code:

<a href="\1">\1</a>

If you wanted to quickly highlight something like:

Code:

http://sample.com

and change it into:

Code:

<a href="http://sample.com">http://sample.com</a>

I would focus on the central tabs that are open when the crash occurs. Especially the tab with the current focus. Is it an xhtml/css file or an opf/ncx file? Does the crash ever occur if only xhtml/css tabs are open when Generate HTML Table of Contents is run?

Or perhaps it only happens right after a resource has been added/removed.

Also, before starting Create HTML TOC, please open the opf tab and make sure you do not have a guide item that already has the toc semantic set. If so, try unsetting it.

One way to make Sigil crash when creating an html toc, it to have the guide have a toc item that points to the one of the main chapters in the book and not a true separate html table of contents file. This causes Sigil to think the same file it is reading to look for h1, h2 tags is actually the one it is trying to rebuild since it thinks that file is already an html toc and that causes the crash.

There were earlier reports of this but I was never able to easily find the difference between a true separate html toc file with proper guide entry and one with a bad guide entry that points to a normal (not a true html toc) file.

ps. If you are willing to share the material via a private link, please pm either DiapDealer or me with a link. I would be happy to test with it and then delete it when the bug has been found and fixed. There are also plugins that replace the text with gibberish that you could use if you so desire.

Quote:

Originally Posted by KevinH (Post 3607399)

Also, before starting Create HTML TOC, please open the opf tab and make sure you do not have a guide item that already has the toc semantic set. If so, try unsetting it.

Actually, I do, so I will give that a try.

Quote:

Originally Posted by KevinH (Post 3607399)

One way to make Sigil crash when creating an html toc, it to have the guide have a toc item that points to the one of the main chapters in the book and not a true separate html table of contents file. This causes Sigil to think the same file it is reading to look for h1, h2 tags is actually the one it is trying to rebuild since it thinks that file is already an html toc and that causes the crash.

Not quite sure what you're saying here, but...

Quote:

Originally Posted by KevinH (Post 3607399)

ps. If you are willing to share the material via a private link, please pm either DiapDealer or me with a link. I would be happy to test with it and then delete it when the bug has been found and fixed. There are also plugins that replace the text with gibberish that you could use if you so desire.

...I'll send you a link so you can scope it out yourself.

In the meantime, on the next book, I'll give that first suggestion a whirl.

Muchos thankses.

Quote:

Originally Posted by Tex2002ans (Post 3607334)

//snip!//

While not exactly what you wanted:

Did you know that there is an Insert Link button:

Attachment 159846

Or you could go into Edit > Preferences > Keyboard Shortcut, and search for "Link":

Attachment 159847

Or you could also create a Clip:

Code:

<a href="\1">\1</a>

If you wanted to quickly highlight something like:

Code:

http://sample.com

and change it into:

Code:

<a href="http://sample.com">http://sample.com</a>

Actually, the Insert Link icon is what I use. But, doggone it! it means I have to move my hand at least an inch or two! (Some people say I'm lazy, but I submit that I'm efficient!) :rofl:

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.

I thought this had been fixed a long time ago. It has not hit me recently.

If I generate the HTML TOC right upon start of the session, usually there was no issue
If I did work, then tried: Crash near the end of the Generate.

Note: I got into the habit of Saving before ANY TOC generation. (that did not prevent the crash, just prevented other losses ;) )

As I said... not seen in quite a while

Wow! I don't want to say that that was quick....but that was quick!

I can change my "workflow" so that I don't set the semantics before creating the TOC, instead doing it afterward. I might add, this issue has only come up with this author, because he has the Table Of Contents From Hell.

Thank you a bunch!

The following change just commited to Sigil master seems to fix this issue on my dev machine (a Mac). Hopefully the same fix will work for all platforms.

Code:

diff --git a/src/Tabs/FlowTab.cpp b/src/Tabs/FlowTab.cpp

index 47ab9d1..8a6deb6 100644

--- a/src/Tabs/FlowTab.cpp

+++ b/src/Tabs/FlowTab.cpp

@@ -112,6 +112,12 @@ FlowTab::~FlowTab()

     // No idea how that's possible but this prevents a segfault...

 

     disconnect(this, 0, 0, 0);

+

+    // or at least it used to, as this signal Modified still fires so try an explicit

+    // disconnect

+

+    disconnect(m_HTMLResource, SIGNAL(Modified()), this, SLOT(ResourceModified()));

+

     m_WellFormedCheckComponent->deleteLater();

 

     if (m_wBookView) {

If anyone can recreate this on other platforms by having the existing html toc open in a CodeView tab (and properly marked in the guide) and then running Tools->Table of Contents->Create Table of Contents, it would be helpful to know that. It would also be useful to know if this "fix" helps.

Thanks for the test case and bug report. I will delete the test case once we confirm the issue is fixed on all platforms.

Quote:

Originally Posted by KevinH (Post 3607666)

Sorry, I didn't mention. I'm on Win-7, SP-2. I'll be doing another book, probably today, and I'll remove the semantics before I do it.

And yes theducks, this bug was "fixed" once before (the comments in the FlowTab destructor are clear on this) but for some reason the simple disconnect that used to fix the problem is now not working or returns before it completes and an explicit disconnect seems to be needed to prevent the flow tab that is being destroyed from being reentered.

Thus the quick patch as I had seen this same bug earlier and thought I had nipped it in the bud, so I am are trying again. The second disconnect may just cause a long enough delay so that the first attempt at full disconnection works but it certainly can not hurt and seems to "fix the problem" on my machine.

Quote:

Originally Posted by JustinThought (Post 3607671)

Sorry, I didn't mention. I'm on Win-7, SP-2. I'll be doing another book, probably today, and I'll remove the semantics before I do it.

If that prevents the crash, then we are on the right track. I will now delete your test epub but please keep a copy for awhile just in case this problem rears its head again as it has in the past.

Thanks,

Kevin

Are there some concrete steps to recreate the crash before I test the patch?

EDIT: nevermind I just noticed this:

Quote:

Originally Posted by KevinH (Post 3607666)

I can't seem to recreate the crash on Linux with those steps (as of yet).

Then it probably only impacts Windows and Mac? Or perhaps is Qt version specific? Does your Windows box show this bug? What Qt version is your Linux build using? My build is using Qt 5.6.2 with official old Qt Webkit added back.