Sigil 2.3.0 crashes when opening Fictionwise epubs

[KevinH]

Thank you!

Yes, according to your debug log, what I added will not help!

The std::runtime_error when Sigil tries to read the missing NCX is being caught in the right place and the Error Dialog is shown. So once you hit the ok button on the Error Dialog, it should have returned and run 34, but instead Sigil is closing or crashing ... but I can not see why ....

Especially as this only happens when Sigil is not already running which makes this even stranger.

I noticed from your debug output you are running Sigil as Maximized. That changes the startup sequence somewhat. Could you try one more time with Sigil's MainWindow NOT Maximized to see if that impacts anything?

[DiapDealer]

I couldn't induce a crash/closing with Dummy2.epub on a physical Windows 10 machine either.

[retiredbiker]

FYI, I just did a new build from Master on my Linux box. Testing with the dummy2 file, I get the message and can view details no matter how it is opened, but I can't get it to crash.

[KevinH]

Originally Posted by retiredbiker

FYI, I just did a new build from Master on my Linux box. Testing with the dummy2 file, I get the message and can view details no matter how it is opened, but I can't get it to crash.

Thank you for trying it on Linux and reporting back. So far this issue only seems to happen on some Windows boxes, not MacOS or Linux.

But it is good to know I have not broken anything! (Yet!)

[KevinH]

If we can not track this down I can prevent the improperly handled exception right in ImportEPUB.cpp but that kind of sidesteps the real problem.

[KevinH]

Originally Posted by DiapDealer

I couldn't induce a crash/closing with Dummy2.epub on a physical Windows 10 machine either.

Wow! That makes this even more strange.

BeckyEbook ran her tests with Sigil's MainWindow Maximized according to her debug output. Could you try the same thing to see if that matters at all?

I am admittedly grasping at straws here.

[DiapDealer]

Originally Posted by KevinH

BeckyEbook ran her tests with Sigil's MainWindow Maximized according to her debug output. Could you try the same thing to see if that matters at all?

I already tried that. It made no difference on either machine.

Originally Posted by KevinH

I am admittedly grasping at straws here.

Nothing wrong with a bit of straw-grasping.

[KevinH]

By any chance is Qt or Sigil compiled on Windows using the compiler equivalent to:

-fno-exceptions

If not, that really only leaves the possibility of a crash happening when the Error Dialog is waiting for the OK button to be pushed.

As BeckyEbook's debug output shows, the missing NCX runtime error is caught in the LoadFile routine in the right place but somehow it crashes after it shows the Error Dialog, ok button.

That is when Qt allows other QEvents to be processed which can be seen in the debug ouput as the MainWindow activation happening but in the first startup case of Sigil, it needs the m_Book properly set before it opens the MainWindow.

Perhaps we catch the runtime error, and immediately use CreateNewBook() *before* we display the Warning message as that might prevent the crash on initial startup It is worth a shot.

[DiapDealer]

I don't add anything like that when building Qt or Sigil. Not to say something like that is not introduced somewhere--just that I'm not knowingly doing it.

One other thing I never thought of is that those building their own Sigil are very likely using my Qt6.7.2 built for GitHub CI. It's not built with link time optimizations (so as to be compatible with any version of VS2022 installed on Github's runner images [or any versions users may have installed]). Whereas I'm using a version built with link time optimizations for releases and for my own Sigil development. I've not made that Qt build available publicly.

When Qt is built with link time code generation enabled, then Sigil MUST be built with the exact same VS toolchain version. Perhaps that's the difference.

I guess I can check pretty easily by building Sigil with my CI version of Qt6.7.2

[KevinH]

Yes linking may impact handling cross module exceptions. So it is plausible I think.

Either way ...

I have now pushed a reordering to the LoadFile routine to MainWindow in Sigil master to test the hypothesis of QEvents being processed out of order on initial startup when the error dialog is shown.

If BeckyEbook tests this change and it does not help, I am going to revert all of these changes then go and prevent the damn exception from being thrown at all in ImportEPUB.cpp to prevent the whole strange sequence of events.

I have already written the code to do that and can push it tomorrow once BeckyEbook reports on her testing of this reordered version.

If it does turn out to be a linking issue, then preventing the exception from being thrown in the first place makes sense as well.

Originally Posted by DiapDealer

I don't add anything like that when building Qt or Sigil. Not to say something like that is not introduced somewhere--just that I'm not knowingly doing it.

One other thing I never thought of is that those building their own Sigil are very likely using my Qt6.7.2 built for GitHub CI. It's not built with link time optimizations (so as to be compatible with any version of VS2022 installed on Github's runner images [or any versions users may have installed]). Whereas I'm using a version built with link time optimizations for releases and for my own Sigil development. I've not made that Qt build available publicly.

When Qt is built with link time code generation enabled, then Sigil MUST be built with the exact same VS toolchain version. Perhaps that's the difference.

I guess I can check pretty easily by building Sigil with my CI version of Qt6.7.2

[DiapDealer]

I'm just not sure any more. The bottom line is that I got it to crash by building a version with the other Qt on my virtual Windows machine. But only if Sigil is maximized. It didn't matter whether it was maximized or not when testing before. What's more... Sigil crashes (only when maximized) regardless of which version of Qt was used in the Sigil build now. So I'm baffled.

What's more: Sigil won't crash on the physical Windows machine no matter which Qt build I use, and no matter if Sigil is maximized or not.

[DNSB]

I tried rebuilding Sigil with the latest update. Opening dummy2.epub is now working in that I can click on Show details and the details show up. It doesn't seem to matter whether Sigil is full screen or windowed.

[DiapDealer]

It's gotta be some sort of race and we're just kicking the can around.

[KevinH]

That is what I thought. On initial start up Sigil expects a certain order for things so that geometry is set first, the restore state is done next when the Main Appilcation is first shown. Using Full Screen and Maximized changes this order a bit since showMaximized() and showFullScreen() do a show (a MainWindow Activation). But before the very first MainWindow can be shown either CreateNewBook() must be run (an empty epub) or an actual epub must be fully loaded.

But the exceptions started to interfere with that order because when showing the Error Dialog and waiting for okay to be pushed, both delayed the running of CreateNewBook() (because the loading of a epub failed) and allowed other QEvents to be processed resulting in the MainWindow being activated before an epub (empty or real) existed.

My last update to MainWindow.cpp makes CreateNewBook() to be called as soon as any Exception is thrown when trying to load an epub so that showing the ErrorDialog can run other QEvents and not cause a problem.

At least that is my current working theory. And @DNSB's testing seems to support that theory but your testing is showing something else is happening related Maximized windows.

So one step forward and one step back all at the same time!

What we really need is to generate a backtrace easily on Windows like we get automatically with MacOS and can easily get with gdb on Linux so we can see the exact sequence of events happening.