Sigil-0.9.991 (1.0 Pre-release)

[CalibUser]

Originally Posted by DiapDealer

That sort of thing would suggest that the images were not properly manifested in the opf file in the first place (and removal would only happen if you saved the epub). Even earlier versions of Sigil couldn't fix wrong hrefs in the manifest when opening, but Sigil should warn you that unmanifested files are present when opening. Did you get no such warning on that particular epub?

I did not see any warnings. I included the images in the epub using the Insert file button on the toolbar in Sigil.

I've noticed that an underlining dash followed by a shorter underlining dash is sometimes appearing in Sigil instead of a space (see line 131 in the section MainText.xhtml of the attached epub - I tried to paste this example in this note but the underlining disappeared from the pasted version). I don't know whether Sigil or PageEdit is inserting these underlining characters.

NB I decided to test Sigil 0.9.991 by developing this epub as a guide to PageEdit 0.9.6. Although the guide contains the underlining dashes mentioned above it is ready for use.

[BeckyEbook]

This "underlining dash followed by a shorter underlining dash" is simply nbsp saved as unicode character (not entity).

[DiapDealer]

Yes. That mark is used to be able to "see" special space characters. They're not actually being inserted into the markup. They just show up in Sigil. You can add the entity to your Preserve Entities list (in Preferences) and they will all be changed to entities on the next Save/Mend.

[DiapDealer]

Originally Posted by CalibUser

I did not see any warnings. I included the images in the epub using the Insert file button on the toolbar in Sigil.

Do you have Mend On Open/Save disabled in the Preferences or anything? I honestly can't recommend unchecking those for any reason any more.

[snarkophilus]

Originally Posted by DiapDealer

PM sent with details.

Ta, got it.

Originally Posted by DiapDealer

Might want to make a backup of your preferences folder before installing 0.9.991 that you could later restore if you wanted to be super-duper safe, but there should be no problems.

Done just in case...

[snarkophilus]

Using 0.991-18, if I open many files (say 20ish) from one book, then click quickly on the close tab red "x" without moving the mouse to close the files, Sigil crashes. This happens for one particular book and is repeatable, but doesn't happen on a couple of other books I tried. This particular book is copyright, so I can't post it here.

I can see a compile time debug option at https://github.com/Sigil-Ebook/Sigil...o/DEBUGGING.md. Is there anything I can do to provide debug output from a standard build, or anything else to help track down where the crash is?

[KevinH]

So you are closing a whole bunch of CodeView Tabs who have tab sizes of about the same and after your mouse once after positioning it once over a tab close x, and repeatedly and quickly closing the tabs. Is that right?

[CalibUser]

Originally Posted by DiapDealer

Do you have Mend On Open/Save disabled in the Preferences or anything? I honestly can't recommend unchecking those for any reason any more.

Yes, I do have these disabled. However, as I was using standard procedures for developing my book that I used with previous versions of Sigil I am not convinced that this was cause of the problem as I had Mend On Open/Save disabled for those too.

Sometime (with older versions of Sigil) I made errors in codeview and saved the file without realising that an error was present. When I later switched to Bookview I would see a warning message asking me whether I want to correct the error manually or have this done automatically accompanied with a warning that if the error is corrected automatically then I may lose data. I always choose to correct the error myself.
As the new version of Sigil does not have Bookview, I will not be aware of coding errors if I save a file that contains these types of errors. If I save a file containing these errors is there a risk that Mend on Save will cause a loss of data?
If I open a file containing these errors later and Mend On Open is enabled is there still a risk of data loss if the file is mended on open?
Also, if the errors

[CalibUser]

@BeckyEbook:

Originally Posted by BeckyEbook

This "underlining dash followed by a shorter underlining dash" is simply nbsp saved as unicode character (not entity).

Thanks, I had not realised this was the unicode representation of nbsp.

[CalibUser]

Originally Posted by DiapDealer

Yes. That mark is used to be able to "see" special space characters. They're not actually being inserted into the markup. They just show up in Sigil. You can add the entity to your Preserve Entities list (in Preferences) and they will all be changed to entities on the next Save/Mend.

Thanks, DiapDealer.

[KevinH]

This one I can recreate:

Exception Codes:       EXC_I386_GPFLT
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   org.qt-project.QtCore         	0x0000000112d05b48 QObject::disconnect(QObject const*, char const*, QObject const*, char const*) + 680
1   com.sigil-ebook.Sigil.app     	0x000000010a1fd57b MainWindow::BreakTabConnections(ContentTab*) + 683
2   com.sigil-ebook.Sigil.app     	0x000000010a1d70f8 MainWindow::ChangeSignalsWhenTabChanges(ContentTab*, ContentTab*) + 24
3   org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
4   com.sigil-ebook.Sigil.app     	0x000000010a24d488 TabManager::TabChanged(ContentTab*, ContentTab*) + 72
5   com.sigil-ebook.Sigil.app     	0x0000000109ee6322 TabManager::EmitTabChanged() + 98
6   org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
7   org.qt-project.QtWidgets      	0x000000010acd983d 0x10aafa000 + 1964093
8   org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
9   org.qt-project.QtWidgets      	0x000000010acbb736 QTabBar::setCurrentIndex(int) + 406
10  org.qt-project.QtWidgets      	0x000000010acbbea1 QTabBar::removeTab(int) + 1217
11  org.qt-project.QtWidgets      	0x000000010acd987e 0x10aafa000 + 1964158
12  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
13  org.qt-project.QtWidgets      	0x000000010acb600e 0x10aafa000 + 1818638
14  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
15  org.qt-project.QtWidgets      	0x000000010ab2db06 QStackedLayout::takeAt(int) + 438
16  org.qt-project.QtWidgets      	0x000000010ab2844f QLayout::removeWidget(QWidget*) + 95
17  com.sigil-ebook.Sigil.app     	0x0000000109ee637c TabManager::DeleteTab(ContentTab*) + 28
18  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
19  com.sigil-ebook.Sigil.app     	0x000000010a24a89c ContentTab::DeleteMe(ContentTab*) + 60
20  com.sigil-ebook.Sigil.app     	0x0000000109ee443b TabManager::CloseTab(int, bool) + 91
21  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
22  org.qt-project.QtWidgets      	0x000000010acd983d 0x10aafa000 + 1964093
23  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
24  org.qt-project.QtWidgets      	0x000000010acba80b QTabBarPrivate::_q_closeTab() + 203
25  org.qt-project.QtCore         	0x0000000112d08bec QMetaObject::activate(QObject*, int, int, void**) + 3132
26  org.qt-project.QtWidgets      	0x000000010abf49ff 0x10aafa000 + 1026559
27  org.qt-project.QtWidgets      	0x000000010abf489c 0x10aafa000 + 1026204
28  org.qt-project.QtWidgets      	0x000000010abf59cf QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 271
29  org.qt-project.QtWidgets      	0x000000010ab4621d QWidget::event(QEvent*) + 445
30  org.qt-project.QtWidgets      	0x000000010ab0a4bd QApplicationPrivate::notify_helper(QObject*, QEvent*) + 269
31  org.qt-project.QtWidgets      	0x000000010ab0d318 QApplication::notify(QObject*, QEvent*) + 7336
32  org.qt-project.QtCore         	0x0000000112cd7994 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 212
33  org.qt-project.QtWidgets      	0x000000010ab0ade0 QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) + 896

So it appears that diconnecting the signals from the deleted tab is causing the segfault. I will try to add some debug print statements in this code to see if we can detect what exactly is going wrong here.

KevinH

Originally Posted by snarkophilus

Using 0.991-18, if I open many files (say 20ish) from one book, then click quickly on the close tab red "x" without moving the mouse to close the files, Sigil crashes. This happens for one particular book and is repeatable, but doesn't happen on a couple of other books I tried. This particular book is copyright, so I can't post it here.

I can see a compile time debug option at https://github.com/Sigil-Ebook/Sigil...o/DEBUGGING.md. Is there anything I can do to provide debug output from a standard build, or anything else to help track down where the crash is?

[theducks]

Originally Posted by CalibUser

Yes, I do have these disabled. However, as I was using standard procedures for developing my book that I used with previous versions of Sigil I am not convinced that this was cause of the problem as I had Mend On Open/Save disabled for those too.

Sometime (with older versions of Sigil) I made errors in codeview and saved the file without realising that an error was present. When I later switched to Bookview I would see a warning message asking me whether I want to correct the error manually or have this done automatically accompanied with a warning that if the error is corrected automatically then I may lose data. I always choose to correct the error myself.
As the new version of Sigil does not have Bookview, I will not be aware of coding errors if I save a file that contains these types of errors. If I save a file containing these errors is there a risk that Mend on Save will cause a loss of data?
If I open a file containing these errors later and Mend On Open is enabled is there still a risk of data loss if the file is mended on open?
Also, if the errors

Some errors still make a Pink box in the Preview pane> I sugges keeping that open, even if you only show the top few lines
( is there any way to color a section tab that has/would have an error box?)

[DiapDealer]

The "quickly closing tabs" crash has been around for a while. I thought I mentioned it early in our port to QWebEngine. But I also seem to remember it was mitigated by some of our early bugfixing/trouble-shooting. I usually had to get pretty crazy about closing a bunch very quickly (with the mouse) to make it happen. I haven't tried hard to make it happen for a long time though.

[DiapDealer]

Also: Gumbo should never eat content like Tidy was prone to do. Some formatting may have to be redone if it fixes something really crazy it encounters, but the content will still be there to be fixed.

I honestly cannot recommend unchecking Mend on Open/Save for any reason any more. The chances of some unfixed error propagating and affecting other Sigil routines is far greater with Mend turned off, in my opinion, than any risk that Mend might potentially butcher anything if it should it happen to encounter invalid markup when saving/opening.

[KevinH]

Hi DiapDealer,

Yes it is the exact same bug. The problem is caused by QTabBar::setCurrentIndex() that makes a call to processEvents() before it has successfully set the current index!

I have no idea why it would do that but if enough QTabBar::removeTab calls are called fast enough the index never gets set properly resulting in segfaults in various places!

bt
* thread #1, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000108d1947a QtCore`QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) + 10
    frame #1: 0x00000001000101df Sigil`TabManager::EmitTabChanged() + 111
    frame #2: 0x0000000108e8fbec QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3132
    frame #3: 0x0000000100e7d83d QtWidgets`___lldb_unnamed_symbol2580$$QtWidgets + 701
    frame #4: 0x0000000108e8fbec QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3132
    frame #5: 0x0000000100e5f736 QtWidgets`QTabBar::setCurrentIndex(int) + 406
    frame #6: 0x0000000100e5fea1 QtWidgets`QTabBar::removeTab(int) + 1217

Here is a snippet of the backtrace showing the entire sequence of events.

I think we will need to disconnect the QTabBar::currentChanged signal before calling QTabBar::removeTab(int) and then manually invoking EmitTabChanged ourselves after the removeTab returns.

Otherwise we are just asking for trouble. The QTabBar::setCurentIndex is very broken in design by invoking processEvents before setting the actual new index.

KevinH

Originally Posted by DiapDealer

The "quickly closing tabs" crash has been around for a while. I thought I mentioned it early in our port to QWebEngine. But I also seem to remember it was mitigated by some of our early bugfixing/trouble-shooting. I usually had to get pretty crazy about closing a bunch very quickly (with the mouse) to make it happen. I haven't tried hard to make it happen for a long time though.