Sigil-0.9.991 (1.0 Pre-release)

[snarkophilus]

Originally Posted by KevinH

BTW, closing the final tab should not be allowed as that will always cause the app to close in Windows and Linux but not on macOSX. The code should prevent the final tab from ever going away.

Are you sure you are actually closing the final tab before the crash, or is it the next to last tab?

I wasn't too clear. When I start Sigil on that epub, it opens Section0001.xhtml in the first tab. So when I close all the images, Section0001.xhtml is still open.

One more bit of info I've just found. Usually I open Sigil via the Open With plugin from Calibre, or just double clicking on an epub file. If I start Sigil from a CMD window, I get a new CMD prompt straight away, so of like the Sigil starts "detached" from the CMD window. However, if I start Sigil from a cygwin window it doesn't "detach" and I then getone of these messages each time I open an image in a tab:

Warning: QObject::connect: No such signal ImageResource::Deleted(Resource)

If Sigil crashes, it finishes with a "Segmentation fault" error. I'm an old Unix guy, and have never programmed in the Windows world. Is there a way I can get that segfault to leave a core file or whatever the Windows equivalent is? Or give a stack trace as it segfaults?

[KevinH]

Unfortunately, I do not think Windows makes it easy to get a core dump.
If there is still one Section0001.xhtml file then, all should be fine.

Yes, Doitsu reported the same warning message. I will look into it but not connecting a signal to a slot should not be causing a segfault.

KevinH

[snarkophilus]

Originally Posted by [KevinH

Unfortunately, I do not think Windows makes it easy to get a core dump.

Yay Windows .

Yes, Doitsu reported the same warning message.

Ahh, I missed that. So Linux and Windows have the same warning.

Originally Posted by Doitsu

I haven't been able to reproduce this bug on my Windows 10 (1909) machine with 0.9.991-21.

I've opened and closed all 50 images twice by pressing CTRL+W and didn't get a crash. Have you installed the Windows 10 1909 update?

One more thought. Did you press and hold down ctrl-W so that it auto-repeated, or did you bang on lots of individual ctrl-W's? This seems to be somewhat timing related. I wasn't able to reproduce problem with fast individual ctrl-W's. I needed the auto-repeat speed to have a chance of reproducing the fault.

[DiapDealer]

Originally Posted by snarkophilus

One more bit of info I've just found. Usually I open Sigil via the Open With plugin from Calibre, or just double clicking on an epub file. If I start Sigil from a CMD window, I get a new CMD prompt straight away, so of like the Sigil starts "detached" from the CMD window. However, if I start Sigil from a cygwin window it doesn't "detach" and I then getone of these messages each time I open an image in a tab:

We've run into all sorts of problems with launching Sigil via calibre's Open With (third-party plugin or integral feature?). Please make sure the crash is repeatable when taking calibre's Open With out of the equation. There's just too many ways that calibre's Qt and Sigil's Qt can get confused. We need to rule that out first. Also, we've given up trying to support the abandoned third party calibre "Open With" plugin. Using Calibre's inherent Open With feature doesn't typically cause the same issues.

I also can't recreate your new cmd window when launching Sigil that way. Sigil does certainly detach itself from the command (as it should--it's not a terminal windows application after all), but no new terminal window gets launched for me.

[snarkophilus]

Originally Posted by DiapDealer

We've run into all sorts of problems with launching Sigil via calibre's Open With (third-party plugin or integral feature?). Please make sure the crash is repeatable when taking calibre's Open With out of the equation. There's just too many ways that calibre's Qt and Sigil's Qt can get confused. We need to rule that out first.

The crash is repeatable when directly using that simple epub I created with just the 50 1x1 images. Calibre is not involved, just double clicking on the epub to start Sigil.

Also, we've given up trying to support the abandoned third party calibre "Open With" plugin. Using Calibre's inherent Open With feature doesn't typically cause the same issues.

I didn't know there was an inherent Open With in Calibre now! I'll ditch the old plugin and switch to that mechanism. That said, I don't think I've noticed any specific issues with the plugin...

I also can't recreate your new cmd window when launching Sigil that way. Sigil does certainly detach itself from the command (as it should--it's not a terminal windows application after all), but no new terminal window gets launched for me.

Sorry, that's a terminology mixup. I meant "it detaches and returns to the CMD prompt straight away, in the same CMD window". I didn't mean that a new CMD window started.

[DiapDealer]

Originally Posted by snarkophilus

Sorry, that's a terminology mixup. I meant "it detaches and returns to the CMD prompt straight away, in the same CMD window". I didn't mean that a new CMD window started.

Oh, OK. That's the expected behavior with Sigil and the Windows command prompt, then. As I mentioned, Sigil is not a Windows terminal program. There is nothing for the terminal to wait on after Sigil launches. After it checks to see whether an epub was passed to Sigil as an argument. It becomes its own process. The terminal can be closed, or left open, it has no effect on the GUI Windows application after launch.

[snarkophilus]

Originally Posted by DiapDealer

Oh, OK. That's the expected behavior with Sigil and the Windows command prompt, then. As I mentioned, Sigil is not a Windows terminal program. There is nothing for the terminal to wait on after Sigil launches. After it checks to see whether an epub was passed to Sigil as an argument. It detaches itself and becomes its own process. The terminal can be closed, or left open, it has no effect on the GUI Windows application after launch.

At this stage, I'm not even going to guess why Sigil doesn't detach then from a cygwin shell! And then lets me see that warning on opening an image. I guess in the normal Windows environment, those warnings just go nowhere?

As I mentioned, I'm a Unix guy so almost never use CMD. Cygwin almost makes Windows usable .

EDIT: Already switched to Calibre's built-in Open with

[DiapDealer]

Originally Posted by snarkophilus

I guess in the normal Windows environment, those warnings just go nowhere?

They go somewhere, just not to the detached terminal. Fancy debug servers can be configured to capture them, though. Trust me: it makes debugging on Windows difficult. With Linux and Mac, one can simply place a qDebug() statement in the code and have it displayed. Not so on Windows. At least not until I just learned that Cygwin's bash terminal captures them, that is!

I worry about what cygwin packages you may have installed that are on the system path, though. Are you just using Cygwin for a bash shell, or do you have any packages like Qt5 or Ssl installed? I tend to use MSYS2/MinGW for any bash-related Windows stuff. I'll have to see if the same is true for that bash shell on windows.

[KevinH]

I have now pushed another fix for this problem which really comes down to a guarded QPointer being updated too quickly causing a collision with the pointer being manually updated when one of its earlier values is being updated to 0 due to the underlying widget it once pointed to being deleted (via a deleteLater).

There was really no reason to make this a QPointer as we manually update it in our own TabManager delete routines, and it is never shared outside the TabManager except via a signal and we generate said signal so we control it. That the signal is sent and processed **before** the underlying tab widget is ever destructed.

With this change, I can no longer get too fast tabs to fail even when using ctrl-W on 50 images.

If this change does not cause other problems, we should be able to put this to rest.

Please grab a new version and give it a try.

[BeckyEbook]

Appveyor was not build, but I was build on my system.

I did eight tests in total.
An interesting case.
After closing 50 tabs with Sigil images do not crash, but when THEN I click again on the first image in BookBrowser – Sigil crash.

Another interesting thing is that if I do tests with the Preview window closed – Sigil not crash. Perhaps the problem is related to the Preview?

If you can add some Debug messages (I don't know where) - I'll do some additional tests. Maybe debug-log analysis will help.

[DiapDealer]

Originally Posted by BeckyEbook

Appveyor was not build, but I was build on my system.

The Windows Appveyor version was built fine. It was the Travis Mac version that failed (not really, but it seems to do that every now and then. It's a Travis glitch of some kind). Make sure you actually click on the red X at github to see if both checks failed or not. I'll re-run the travis build and it will be fine too.

[KevinH]

Just pushed yet another related fix to prevent stale info from ever being left in m_LastContentTab in TabManager.cpp (and to quiet that annoying warning) which became necessary since we moved away form using a guarded QPointer for it.

This now handles the problem.

BTW: debug builds and debug output are really only needed if I can either not recreate the issue or can not get a decent backtrace. In all of these cases of closing tabs too fast, I have been able to recreate things and get good traces. qDebug info would not have helped.

All of these troubles are because QTabWidget::setCurrentIndex() makes a call to Qt's processEvents() **BEFORE** returning which emits the currentChanged() signal before the new state has officially been implemented.

So whenever we add a new tab or remove a tab, we must actually disconnect that signal and manually reconnect it afterwards to prevent the nonsense that Qt is inflicting on us.

This should finally do the trick.

Please git it a try.

KevinH

[BeckyEbook]

Last commit works!
I tried several times and never crashed.

@DiapDealer. You're right. I didn't look exactly. Anyway, my build is usually faster than Appveyor.

[KevinH]

Hi BeckyEbook,

Thanks for testing it! Glad to hear we can remove that bug from our list!

Kevin

Originally Posted by BeckyEbook

Last commit works!
I tried several times and never crashed.

@DiapDealer. You're right. I didn't look exactly. Anyway, my build is usually faster than Appveyor.

[DiapDealer]

Originally Posted by BeckyEbook

@DiapDealer. You're right. I didn't look exactly. Anyway, my build is usually faster than Appveyor.

Gotcha. I'm usually using Windows VMs on my main Linux machine for building Sigil, so Appveyor is often faster than the 2 cores with 4Gb of RAM I can devote to the VM. But these days, I only boot my physical Windows 10 SSD when I need to compile something like Qt\QtWebEngine from scratch.

Thanks for the testing you've done!