Sigil 2.8.6 crashes on Windows11 when adding a cover to a large EPUB3 - Page 2

DNSB · Yesterday, 09:42 PM

Edited my message to reflect testing the fixed epub.

DiapDealer · Yesterday, 09:44 PM

Quote:

Originally Posted by KevinH

My bad, that test epub was missing almost all of its spine. That was the point of that test epub!

Phew! I thought I was losing my mind!

I can confirm that there's no crash, and no spine jumbling, using the fixed 2500files epub on a fairly tired Windows 10 laptop using Sigil 2.8.6. It takes a bit, but I honestly thought it would be slower.

DiapDealer · Yesterday, 09:52 PM

We still probably need to find out how massive the OP's epub really is. It could contain thousands of images which would increase the size of the manifest that lxml would need to parse.

KevinH · Yesterday, 10:09 PM

Perhaps the OP is using/trying with an epub2, which will take much longer and invoke python more often due to looking for the guide entry for cover (if you have 2500 files the opf will be parsed 2500 times looking to see if that resource has the cover semantic set).

I can certainly speed that up for the next release by extracting the entire guide once and storing it in a hashtable for fast lookups.

Luckily parsing an epub3 nav for landmark codes is much much faster as it uses gumbo and not python lxml.

But the OP specified epub3 in the thread title, so ...

rinsay · Yesterday, 10:23 PM

I tried the same EPUB file on another Windows 11 PC, and Sigil 2.8.6 worked fine. The PC that’s having issues has 32GB of memory, so I don’t think it’s a case of insufficient memory. Maybe something wrong with my PC, but I’m not sure exactly what it is.

KevinH · Yesterday, 10:58 PM

We would still appreciate a copy of that epub so we can run some tests ourselves. If you can't provide us a link to it privately, then at least provide more information on its composition.

How many chapter files?
How many image files?
How many css and font files?
Average, maximum, and minimum size in kilobytes for image, chapter, font files, etc.

Total overall size of the epub in mb?

Most of this information can be gleaned by running the Reports that Sigil generates on the epub.

With this we can hopefully generate our own test epub but of course a copy of the actual epub that caused the issue in the first place would be much more helpful. There are plugins that can scramble the text to protect your copyright. See the Borkify plugin in our Plugin Index.

rinsay · Today, 12:37 AM

I have already sent you a private message on MobileRead and provided a download link for the original file.

KevinH · Today, 09:02 AM

Thank you. It is very very much like our own test case. No images, lots of short text files.

On my Mac and on an old Linux box, I had no problems adding an image file and adding a cover to it but it was slow.

But I will continue testing with it to try to improve Sigil's speed so that adding a cover is not as slow for our next release.

Still not sure why your machine did what it did, but my best guess based on what you first posted would be a stack overflow of some sort calling into Python.

rinsay · Today, 09:14 AM

I used ChatGPT to analyze this problem on my computer, and now I've found the cause. Below are the GPT analysis conclusions, which worked for me.

This crash is most likely due to a problem with the local CPU platform's stability. The same EPUB and the same parser produce different results when run on a different logical processor.

The Sigil parser can be reproduced independently. I repeatedly parsed the nav.xhtml file in 2203.epub using the installed sigilgumbo.dll. When pinned to logical processor CPU 10, heap corruption or access violations occurred multiple times, consistent with the Sigil crashes recorded by Windows. When pinned to CPU 12, each round of 600 parsing attempts completed successfully.

You can try this: First, open Sigil, in Task Manager's "Details" tab, right-click Sigil.exe → "Set Affinity", uncheck "CPU 10", then open the EPUB copy and add the cover. This method has been verified with standalone parsers and EPUBCheck.

Your CPU is an i7-13700KF, currently running BIOS version 1802 with microcode 0x12B. Intel has listed this model as potentially affected by Vmin Shift instability and recommends using Intel Default Settings and a BIOS containing microcode 0x12F or later.

KevinH · Today, 09:24 AM

So really nothing to do with Sigil at all. Thanks for the update!

DiapDealer · Today, 09:30 AM

You should be able to create a batch file that would launch Sigil with the preferred affinity on that particular machine.

Code:

@echo off
start /normal /affinity <HEX_MASK> "WindowTitle" "C:\Path\To\YourApp.exe"
exit

/affinity <HEX_MASK>: Replace <HEX_MASK> with a hexadecimal code representing the CPU cores you want to assign.

"WindowTitle": Required placeholder for the window title (can be left empty like "").

"C:\Path\To\YourApp.exe": The full path to the executable you want to launch.

Here's an online cpu affinity mask calculator if it helps: https://bitsum.com/tools/cpu-affinity-calculator/

KevinH · Today, 11:44 AM

On the good news front, with the OP's test case I was able to speed up AddCover from 24 seconds to just under 1 second. Similar speedups happen with our own test case although it is faster naturally.

The basic idea is to grab the complete guide or nav landmarks semantic codes in a QHash<QString, QStringList> where the key is the files BookPath (html_resource->GetRelativePath()) just once.

Then when looping through all resources you check that hash to determine if it has the "cover" semantic set. This prevents Sigil from parsing the opf or nav 2500 times to check each html resource. So it can save lots of parsing of the OPF (epub2) or Nav (epub3) and thereby saves lots and lots of python lxml sanity check parsing of the opf, or gumbo parsing of the nav.

It should have been designed that way from the start but I never thought about epubs with multiple thousands of chapters when we designed the code originally. Most epubs have way under 100 chapters.

I have now pushed these speedups to master. They will appear in the next release of Sigil.

JSWolf · Today, 02:46 PM

I've converted the test ePub to ePub2 to test.

DiapDealer · Today, 02:47 PM

Quote:

Originally Posted by JSWolf

I've converted the test ePub back to ePub2 for anyone to test.

I'm pretty sure Kevin had the original that he converted to epub3 in the first place, but....

DNSB · Today, 02:50 PM

For Windows users, you can download an updated version from the link in the Downloading Sigil test builds for Windows.

Yesterday, 10:09 PM	#19
KevinH Sigil Developer Posts: 10,211 Karma: 7640000 Join Date: Nov 2009 Device: many	Perhaps the OP is using/trying with an epub2, which will take much longer and invoke python more often due to looking for the guide entry for cover (if you have 2500 files the opf will be parsed 2500 times looking to see if that resource has the cover semantic set). I can certainly speed that up for the next release by extracting the entire guide once and storing it in a hashtable for fast lookups. Luckily parsing an epub3 nav for landmark codes is much much faster as it uses gumbo and not python lxml. But the OP specified epub3 in the thread title, so ... Last edited by KevinH; Yesterday at 10:18 PM.

Yesterday, 10:58 PM	#21
KevinH Sigil Developer Posts: 10,211 Karma: 7640000 Join Date: Nov 2009 Device: many	We would still appreciate a copy of that epub so we can run some tests ourselves. If you can't provide us a link to it privately, then at least provide more information on its composition. How many chapter files? How many image files? How many css and font files? Average, maximum, and minimum size in kilobytes for image, chapter, font files, etc. Total overall size of the epub in mb? Most of this information can be gleaned by running the Reports that Sigil generates on the epub. With this we can hopefully generate our own test epub but of course a copy of the actual epub that caused the issue in the first place would be much more helpful. There are plugins that can scramble the text to protect your copyright. See the Borkify plugin in our Plugin Index. Last edited by KevinH; Yesterday at 11:13 PM.

Today, 09:30 AM	#26
DiapDealer Grand Sorcerer Posts: 29,929 Karma: 212736631 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	You should be able to create a batch file that would launch Sigil with the preferred affinity on that particular machine. Code: @echo off start /normal /affinity <HEX_MASK> "WindowTitle" "C:\Path\To\YourApp.exe" exit /affinity <HEX_MASK>: Replace <HEX_MASK> with a hexadecimal code representing the CPU cores you want to assign. "WindowTitle": Required placeholder for the window title (can be left empty like ""). "C:\Path\To\YourApp.exe": The full path to the executable you want to launch. Here's an online cpu affinity mask calculator if it helps: https://bitsum.com/tools/cpu-affinity-calculator/ Last edited by DiapDealer; Today at 10:04 AM.

Today, 11:44 AM	#27
KevinH Sigil Developer Posts: 10,211 Karma: 7640000 Join Date: Nov 2009 Device: many	On the good news front, with the OP's test case I was able to speed up AddCover from 24 seconds to just under 1 second. Similar speedups happen with our own test case although it is faster naturally. The basic idea is to grab the complete guide or nav landmarks semantic codes in a QHash<QString, QStringList> where the key is the files BookPath (html_resource->GetRelativePath()) just once. Then when looping through all resources you check that hash to determine if it has the "cover" semantic set. This prevents Sigil from parsing the opf or nav 2500 times to check each html resource. So it can save lots of parsing of the OPF (epub2) or Nav (epub3) and thereby saves lots and lots of python lxml sanity check parsing of the opf, or gumbo parsing of the nav. It should have been designed that way from the start but I never thought about epubs with multiple thousands of chapters when we designed the code originally. Most epubs have way under 100 chapters. I have now pushed these speedups to master. They will appear in the next release of Sigil. Last edited by KevinH; Today at 12:04 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Plugin] ePub3-itizer - epub3 output plugin for Sigil	KevinH	Plugins	458	10-04-2026 11:07 AM
Two problems in Sigil 2.7.0 in Windows11	philja	Sigil	22	02-06-2026 09:32 AM
Adding Images Crashes Sigil	Paredon	Sigil	7	10-19-2023 01:34 AM
Epub crashes on Sigil for Mac, OK on Sigil for PC	crystamichelle	Sigil	6	08-14-2013 03:52 PM
Sigil adding blank page after cover image	ebookn00b	Sigil	32	06-20-2013 02:44 PM

Yesterday, 09:42 PM	#16
DNSB Bibliophagist Posts: 55,754 Karma: 182800000 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Edited my message to reflect testing the fixed epub.

Yesterday, 09:52 PM	#18
DiapDealer Grand Sorcerer Posts: 29,929 Karma: 212736631 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	We still probably need to find out how massive the OP's epub really is. It could contain thousands of images which would increase the size of the manifest that lxml would need to parse.

Yesterday, 10:23 PM	#20
rinsay Junior Member Posts: 4 Karma: 10 Join Date: Nov 2026 Device: iReader Ocean5 Pro	I tried the same EPUB file on another Windows 11 PC, and Sigil 2.8.6 worked fine. The PC that’s having issues has 32GB of memory, so I don’t think it’s a case of insufficient memory. Maybe something wrong with my PC, but I’m not sure exactly what it is.

Today, 12:37 AM	#22
rinsay Junior Member Posts: 4 Karma: 10 Join Date: Nov 2026 Device: iReader Ocean5 Pro	I have already sent you a private message on MobileRead and provided a download link for the original file.

Today, 09:02 AM	#23
KevinH Sigil Developer Posts: 10,211 Karma: 7640000 Join Date: Nov 2009 Device: many	Thank you. It is very very much like our own test case. No images, lots of short text files. On my Mac and on an old Linux box, I had no problems adding an image file and adding a cover to it but it was slow. But I will continue testing with it to try to improve Sigil's speed so that adding a cover is not as slow for our next release. Still not sure why your machine did what it did, but my best guess based on what you first posted would be a stack overflow of some sort calling into Python.

Today, 09:14 AM	#24
rinsay Junior Member Posts: 4 Karma: 10 Join Date: Nov 2026 Device: iReader Ocean5 Pro	I used ChatGPT to analyze this problem on my computer, and now I've found the cause. Below are the GPT analysis conclusions, which worked for me. This crash is most likely due to a problem with the local CPU platform's stability. The same EPUB and the same parser produce different results when run on a different logical processor. The Sigil parser can be reproduced independently. I repeatedly parsed the nav.xhtml file in 2203.epub using the installed sigilgumbo.dll. When pinned to logical processor CPU 10, heap corruption or access violations occurred multiple times, consistent with the Sigil crashes recorded by Windows. When pinned to CPU 12, each round of 600 parsing attempts completed successfully. You can try this: First, open Sigil, in Task Manager's "Details" tab, right-click Sigil.exe → "Set Affinity", uncheck "CPU 10", then open the EPUB copy and add the cover. This method has been verified with standalone parsers and EPUBCheck. Your CPU is an i7-13700KF, currently running BIOS version 1802 with microcode 0x12B. Intel has listed this model as potentially affected by Vmin Shift instability and recommends using Intel Default Settings and a BIOS containing microcode 0x12F or later.

Today, 09:24 AM	#25
KevinH Sigil Developer Posts: 10,211 Karma: 7640000 Join Date: Nov 2009 Device: many	So really nothing to do with Sigil at all. Thanks for the update!

Today, 02:50 PM	#30
DNSB Bibliophagist Posts: 55,754 Karma: 182800000 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	For Windows users, you can download an updated version from the link in the Downloading Sigil test builds for Windows.