Find replace history not saved between sessions

[DiapDealer]

Originally Posted by KevinH

BTW, is the TOC dockwidget the only one that has impact? Does closing other dockwidgets help?

Not that I could tell. I had all of them closed when I noticed things were working normally. So I started adding them back in one by one to find which one was causing the problem. Even if the ToC is the only dockwidget open the problem will persist. Conversely, all dockwidget open except for the ToC will work normally (other than the persistent segfault, that is).

It also doesn't seem to matter what widgets the toc is sharing space with (if any). Or which dockarea it's in.

One thing I didn't try was docked vs floating.

[KevinH]

Wow! I have been staring at both the TOC and FindReplace code and I can not see how or why any interaction is being created. Find and Replace is a QWidget and part of the MainWindow from the start and the TOC is a QDockWidget that is created later. I could see no signals crossing over either.

So why just having the TOC open could in any way impact the FindReplace code has me stumped. It may be memory corruption of some sort but that typically is random and moves around.

I do not even know how to begin to track this one down!

[KevinH]

Perhaps, just raising the bar for the minimum Qt version makes the most sense here?

[DiapDealer]

Originally Posted by KevinH

Perhaps, just raising the bar for the minimum Qt version makes the most sense here?

Probably. Still ... even though things seem to point toward 5.9.5 being the culprit, I can't help but think the consistent way this manifests (weird as it is) suggests that there might be a way to work around it.

[KevinH]

Could be. If we could track down the actual code in Qt that causes the problem we may be able workaround it. There were LTS releases after 5.9.5 right? Perhaps testing each Qt version going up would tell us when the fix went into Qt and that may help us.

[poxi1023]

Originally Posted by KevinH

Could be. If we could track down the actual code in Qt that causes the problem we may be able workaround it. There were LTS releases after 5.9.5 right? Perhaps testing each Qt version going up would tell us when the fix went into Qt and that may help us.

Not yet; Ubuntu 20.04, scheduled for this April, will be the next LTS release.

[pazos]

Originally Posted by DiapDealer

@pazos (earlier in the thread) is building Sigil against Qt 5.14.x on the same version of Ubuntu as poxi1023. I'm assuming he's using a binary version from Qt.

Yeah, I'm using the official installer from download.qt.io. AFAICT new downloads will require a qt account.

Most -legacy- Debian based distros are stuck with qt 5.9.5. Probably things will change with ubuntu 20.04.

Did you guys consider releasing an appImage? This way it should work even on old distros and qt can be patched as in other platforms, to get rid of upstream bugs like https://bugreports.qt.io/browse/QTBUG-79778.

[DiapDealer]

Originally Posted by poxi1023

Not yet; Ubuntu 20.04, scheduled for this April, will be the next LTS release.

I think he meant other Qt LTS versions being available in general, not just from Ubuntu repos.

And yes, there are installers available for Qt5.9.6 - 5.9.9. Then you have to go to 5.12 for the next LTS (even though Qt clearly has no real respect for what LTS is actually supposed to mean).

If I can make it work correctly with one of those later 5.9.x versions, we may have a shot at seeing what changed in Qt's codebase. That might give us a clue as to how to work around it.

But I'm going to take a few easy stabs in the dark before I go that route.

In the meantime, you do know that you can install Qt5.12.x to build Sigil against without messing up, or affecting your system's 5.9.5 version, right? That's what @pazos is doing. Get it while you can, though. Eventually binary versions of LTS Qts will only be available to paying customers.

[DiapDealer]

Originally Posted by pazos

Did you guys consider releasing an appImage? This way it should work even on old distros and qt can be patched as in other platforms, to get rid of upstream bugs like https://bugreports.qt.io/browse/QTBUG-79778.

I've watched someone else fight the appImage for Sigil project. They ran into unique issues (related to the python plugin framework, I believe) that I'm not sure were ever resolved. Anyone has my blessing to try, but I have no interest in being the/an appImage Sigil maintainer.

We patch that bug in the Qt deployed with our Windows and Mac Sigil installers, by the way.

[DiapDealer]

Originally Posted by DiapDealer

But I'm going to take a few easy stabs in the dark before I go that route.

My first blind stab might have been fruitful!

@poxi1023, if you would try one simple change to src/MainUI/MainWindow.cpp for me, I'd appreciate it.

Change line MainWindow.cpp 247 from:

#ifdef Q_OS_MAC

to:

#ifndef Q_OS_WIN32

With that one change (from the original source), I'm able to see all the correct events/destructors firing and all the preferences get flushed to disk even when the ToC dockwidget is open when closing Sigil.

I still get the QtWebEngineWidgets segfault everytime, mind you, but F&R preferences are correctly saved.

[poxi1023]

Originally Posted by DiapDealer

My first blind stab might have been fruitful!

@poxi1023, if you would try one simple change to src/MainUI/MainWindow.cpp for me, I'd appreciate it.

Change line MainWindow.cpp 247 from:

#ifdef Q_OS_MAC

to:

#ifndef Q_OS_WIN32

With that one change (from the original source), I'm able to see all the correct events/destructors firing and all the preferences get flushed to disk even when the ToC dockwidget is open when closing Sigil.

I still get the QtWebEngineWidgets segfault everytime, mind you, but F&R preferences are correctly saved.

Thank you, DiapDealer!
Your change fixed my problem!

[DiapDealer]

Great! Thanks for reporting back. I'll see how best to incorporate the fix in master. Not sure if that's safe/wise to do for all Linux builds, or if I should limit it to when older Qt versions are being used.

[KevinH]

Great Job!

That code is there for macOS since we use multiple MainWindows at the same time. So exiting a MainWindow is not the same as exiting the entire application as it is for Linux and Windows. This helps to speed that process and keep the overall memory footprint smaller on macOS.

If that helps, then Qt 5.9.5 is very very broken as invoking all destructors on the way out has been part of C++ spec from the very very beginning. You just can not skip destructors if the app is exiting.

Perhaps the order of destructing key objects matters for some reason?

And I still do not know why or how that using WriteSettings in the call to close() did not fix this unless it is the QSettings writing itself that gets broken somehow and writing to it gets lost. And how did the call to close and its debug statement not show up?

Very strange!

Using this code should not hurt things for Windows or Linux unless order of running the destructors matters.

It does force the TOC destructor to be called before the FindReplace destructor, so maybe that is why it helps. It also forces the Preview Window to be destructed last because of early segfaults in QWebEngine that I remembered from Qt5.11.

[DiapDealer]

Part of the reason trying this occurred to me is that of the three dockwidgets that mainwindow loads/shows by default (Preview, BookBrowser and ToC), ToC was the only one that didn't have an explicit destructor function. I realize there doesn't necessarily need to be one (the Clips and Validator dockwidgets come to mind), but I was thinking maybe there was something that wasn't getting properly cleaned up (because of a potential defect in that version of Qt) that perhaps explicitly deleting would take care of.

I might take some time to reorder those explicit deletes for mac and see if there is indeed an order that can produce adverse effects in Linux with Qt 5.9.5.

At this point, I think I'm writing off the segfault as something that's not getting cleaned up in 5.9.5 that doesn't really matter since Sigil is being destroyed anyway.

[KevinH]

If you simply swap those two lines to destruct FindReplace right before TOC and the TOC was open, I would love to know if the problem comes back. If so, then something about the TOC still existing seems to trigger things.

Nicely done!