Sigil "1.9.20" on "Qt 5.12.9" crashing on "Windows 10"

[AntoniDol]

Since I'm using Sigil as production software, it's no longer acceptable the software crashes a few times during editing sessions.

Sigil 1.9.20 on Qt 5.12.9 crashes on Windows 10 when I save an edited file or open a file while editing. Even though I save quite regularly nowadays, I still lose work and valuable time every time Sigil just halts shortly and then vanishes.

Is there a way to see what happens, like an internal log or crash log file, so I can do something about it?

Thanks in advance

[KevinH]

It is never acceptable for Sigil to crash. We have tracked down and fixed all that have been reported. Please post a test epub and a set of reproducible steps that cause the crash and we will get it fixed.

Unfortunately Windows does not provide a full backtrace by default to the user.

Perhaps a Windows person can figure out a way to get a real backtrace of your next crash.

Also there are Windows system shell extensions that can cause great instability in all Qt apps like calibre and Sigil. Calibre's website has a list of known problem software in their FAQs. See their link for more info:
https://manual.calibre-ebook.com/faq...s-occasionally

Please verify Sigil still crashes when you disable extensions when booting Windows.

Also verify the issues are not caused by anti-virus software.

Also verify you are not leaving Sigil running with an open epub over multiple days as some Windows security settings will auto delete files in tmp open for more that 24 hours. Either turn off that self cleaning Windows setting or set Sigil preferences to use your own created folder outside of tmp.

Also verify system tmp is not on a networked drive as this can cause file locking issues.

Based on all of my testing Sigil 1.9.20 on linux and macos is rock steady. I assume the same holds for Windows. At least this is the first crash report in quite a while.

If Qt version matters, it is probably a clash with a Qt version in some other app or system extension.

[KevinH]

FYI: If the crash is associated with file open dialogs or file selection dialogs it is almost certainly caused by a Windows third party file or shell system extension you have in your system or a bad usb device driver. Many of these third party system shell extensions do not properly protect/hide the older Qt version they are linked with and so cause crashes when loaded into memory with newer Qt using software. That calibre faq link lists a number of known bad shell extensions.

Try reading and checking if you have one of those bad third party shell extension installed. Some are default installed by the computers manufacturer, not Windows.

[DiapDealer]

I haven't had Sigil crash on Windows 10 (on multiple hardware setups) in quite some time. Been no new reports (aside from this one) that I know of either.

[Ashjuk]

Originally Posted by DiapDealer

I haven't had Sigil crash on Windows 10 (on multiple hardware setups) in quite some time. Been no new reports (aside from this one) that I know of either.

Me neither.

In fact I can't recall ever having Sigil crash on me.

[KevinH]

That is good to hear that it has been stable on Windows as well.

My guess is that most likely it is a bad Windows shell extension. Those programs should have been statically linked with their older Qt libraries and then stripped of linkable symbols but apparently they were not.

[Pargeo]

Originally Posted by KevinH

That is good to hear that it has been stable on Windows as well.

My guess is that most likely it is a bad Windows shell extension. Those programs should have been statically linked with their older Qt libraries and then stripped of linkable symbols but apparently they were not.

I regret to inform that Sigil (it should be the latest version, I installed it approx a month ago) ALWAYS crushes when I hit Ctrl+2. On my machine (Windows 10, with all patches installed), ctrl+2 is assigned to switch to a specific keyboard layout (I’ve got 4 installed on my machine, for various languages). I thought this was due because of a conflict with Sigil’s own Ctrl+2 used to insert h2, but even when I disabled this shortcut, Sigil kept crashing when I hit ctrl+2.

[KevinH]

Thank you for your bug report:

I wish more people would report crashes when they happen so that they can be tracked down and eliminated. It can only help.

Repeatable crashes can always be fixed if we can recreate them.

I added 3 keyboard layouts to my mac and changed them when Sigil was running with no difficulties. I even modified the change keyboard layout shortcut to match the default Ctrl+2 (h2 Sigil shortcut) to match your case. The Ctrl+2 key event is properly intercepted by the OS which properly changes the keyboard layout. That shortcut never reaches the Sigil app at all. No issues whatsoever.

So whatever is causing this is Windows or system specific and does not happen with macOS.

Is anyone else who uses Linux or Windows seeing similar crashing when changing keyboard layouts?

We will need more info please to track this down:

1. What keyboard layouts do you have installed? Which one causes the crash?

2. What else on your system uses the Ctrl+2 shortcut?

3. Have you tried rebooting Windows into safe mode to prevent broken shell extensions from loading?

4. Does the problem keyboard layout use a different IM or result in a different keyboard driver being used?

5. Have you tried changing the keyboard change shortcut key Ctrl+2 sequence to something else to see if that impacts the issue?


Any details that could help us recreate the crash would be very useful.

Thanks,

KevinH

Originally Posted by Pargeo

I regret to inform that Sigil (it should be the latest version, I installed it approx a month ago) ALWAYS crushes when I hit Ctrl+2. On my machine (Windows 10, with all patches installed), ctrl+2 is assigned to switch to a specific keyboard layout (I’ve got 4 installed on my machine, for various languages). I thought this was due because of a conflict with Sigil’s own Ctrl+2 used to insert h2, but even when I disabled this shortcut, Sigil kept crashing when I hit ctrl+2.

[Pargeo]

Originally Posted by KevinH

Thank you for your bug report:

I wish more people would report crashes when they happen so that they can be tracked down and eliminated. It can only help.

Repeatable crashes can always be fixed if we can recreate them.

I added 3 keyboard layouts to my mac and changed them when Sigil was running with no difficulties. I even modified the change keyboard layout shortcut to match the default Ctrl+2 (h2 Sigil shortcut) to match your case. The Ctrl+2 key event is properly intercepted by the OS which properly changes the keyboard layout. That shortcut never reaches the Sigil app at all. No issues whatsoever.

So whatever is causing this is Windows or system specific and does not happen with macOS.

Is anyone else who uses Linux or Windows seeing similar crashing when changing keyboard layouts?

We will need more info please to track this down:

1. What keyboard layouts do you have installed? Which one causes the crash?

2. What else on your system uses the Ctrl+2 shortcut?

3. Have you tried rebooting Windows into safe mode to prevent broken shell extensions from loading?

4. Does the problem keyboard layout use a different IM or result in a different keyboard driver being used?

5. Have you tried changing the keyboard change shortcut key Ctrl+2 sequence to something else to see if that impacts the issue?


Any details that could help us recreate the crash would be very useful.

Thanks,

KevinH

Hi again, sorry for a late reply,

I've just tested Sigil 1.9.20 for Windows on two machines - a plain vanilla Windows 10 desktop and a Macbook Pro with Sigil installed on Windows 10 installed through Parallels (both have almost the same set of languages (keyboards) installed: UK English (Ctrl+1), Russian (Ctrl+2), Italian (Ctrl+3) and French (Ctrl+4) - only on the desktop. On both systems, hitting Ctrl+2, Ctrl+3 (and Ctrl+4 on the desktop) while in Sigil causes its crash, while Ctrl+1 does not. Selecting a required language using any other method (status bar, touch bar etc.) does not cause a crash (Hitting a 'non-assigned' Ctrl+number combination on both machines does not cause a crash, i.e. Ctrl+4 on MBP + Windows + Parallels does not.)
NB it's only Sigil that crashes when I hit these CTRL+number combinations, any other software works perfectly.
I haven't checked the machines in Safe Mode, the first one because its keyboard driver seems not to be compatible with Safe Mode and only works in the normal mode, and as for the second machine, well, I believe since these two machines are completely different in every way, except for being set for CTRL+ combinations turning on a specific IME, the problem is not in the hardware.
Please note that in order for this experiment be clear, I disabled Sigil-own CTRL+ shortcuts on both machines, but, as you see, this didn't help.

I tried to change the shortcut keys for my languages from CTRL+number to Left Alt-Shift+number. This combination works on both machines without causing any crash. (neither Ctrl+number, nor Left-Alt+number)
Unfortunately, I cannot use it, because it requires pressing three keys and not two and it's really inconvenient for me (my work depends on the speed of typing) and I will not keep this new 'working' shortcuts on either machine.

I hope this helps.

[KevinH]

It does.

1. If changing to a different shortcut still works to change keyboard layout without any crashing of Sigil, the actual changing of the keyboard layout itself can not be the underlying cause of the crash. Keyboard layouts can be changed successfully even by shortcut with no crashes.

2. Assuming Ctrl+2 works properly on Sigil to make text h2 (when *not* assigned to change keyboard layouts), the actual shortcut is not the problem either.

Given 1 and 2 that implies that Ctrl+2 is probably changing something else on your system besides just the keyboard layout (perhaps changing tabs, changing os workspaces, changing monitors, or ...) which is what is giving Sigil fits and causing the crash.

What bothers me is that if no keyboard layout (say the 4th) exists then Ctrl+4 does nothing (no crash at all) so that is inconsistent in that it implies some relation with changing keyboard layouts and Sigil which is inconsistent with the above.

Is there any error message at all?

Are you 100% sure it is a crash and not just hiding the Sigil window someplace off screen on another workspace or monitor or quitting out of Sigil? Have you tried checking the task manager to verify the program has exited completely?

Also just to rule out QtWebEngine, can you please try reproducing the crash when Preview has been turned off (use the Sigil View menu to hide it)? Does that change anything?

Addendum:
A search of the web showed some hits for similar issues on Windows 10 with other software including Excel, Office 365, and etc.

See for example:
https://adobe-video.uservoice.com/fo...s-aftereffects

[DiapDealer]

How are the ctrl+1-4 shortcuts being assigned to the language change? Is it a built-in Windows thing, or a third-party shortcut manager of some kind?

[Pargeo]

Originally Posted by DiapDealer

How are the ctrl+1-4 shortcuts being assigned to the language change? Is it a built-in Windows thing, or a third-party shortcut manager of some kind?

It’s a built-in Windows thing.

[Pargeo]

Originally Posted by KevinH

It does.

1. If changing to a different shortcut still works to change keyboard layout without any crashing of Sigil, the actual changing of the keyboard layout itself can not be the underlying cause of the crash. Keyboard layouts can be changed successfully even by shortcut with no crashes.

2. Assuming Ctrl+2 works properly on Sigil to make text h2 (when *not* assigned to change keyboard layouts), the actual shortcut is not the problem either.

Given 1 and 2 that implies that Ctrl+2 is probably changing something else on your system besides just the keyboard layout (perhaps changing tabs, changing os workspaces, changing monitors, or ...) which is what is giving Sigil fits and causing the crash.

What bothers me is that if no keyboard layout (say the 4th) exists then Ctrl+4 does nothing (no crash at all) so that is inconsistent in that it implies some relation with changing keyboard layouts and Sigil which is inconsistent with the above.

Is there any error message at all?

Are you 100% sure it is a crash and not just hiding the Sigil window someplace off screen on another workspace or monitor or quitting out of Sigil? Have you tried checking the task manager to verify the program has exited completely?

Also just to rule out QtWebEngine, can you please try reproducing the crash when Preview has been turned off (use the Sigil View menu to hide it)? Does that change anything?

Addendum:
A search of the web showed some hits for similar issues on Windows 10 with other software including Excel, Office 365, and etc.

See for example:
https://adobe-video.uservoice.com/fo...s-aftereffects

Hi,
I just tried Sigil with Preview closed - and it crashed again.
The crash message is (not responding) on Sigil's window top and then, when I close it, it says 'Sigil.... is not responding. .. Close the program | Wait for the program to respond. In short, a usual window when you try to close up a program that freezes up.

As for precedents, I remember I got a very similar effect on a version of MS Office, but it was ages ago (at least 10 years ago, or maybe more.). It was similar, but a little bit different - I'd open an Office program and first of all use a task bar to switch to any other language, and once I did that, every subsequent Ctrl+ would not cause any crash. (I remember I wrote to MS several times about it, but didn't obtain any reply.)
I tried to do the same with Sigil, but, alas, it doesn't work - even if I use a different method for switching IMEs first, any subsequent Ctrl+ (assigned to kbd changing) causes a crash.

[DiapDealer]

So it's not actually crashing, but rather becomes hung/unresponsive?

[KevinH]

And have you tried waiting for a full minute or even 2 to see if it ever stopped hanging?
Previously was searching for an actual crash (sig segfault) instead of hanging. I will search on that to see what if anything I can find.