Sigil "not responding - must close" repeatedly

[Trane]

Thanks so much Kevin but before I read these, I installed that little program (WhatIsHang) and it's GREAT. Sigil hung again and the program captured everything in readable text (almost entirely) and created an 87kb report, which I copied into Metapad and zipped and sent to you as requested. It named an api call as the culprit, and I saw similar language in the bits of readable text in the original dump file. I will hang on to the dump in case, but I'm hoping the file I sent will shed light.

Thanks again for helping!

EDIT: If for some reason the .dmp file is easier for you using debug or python tools, just let me know and I will send it zipped as requested. The WhatISHang file was pretty complete though to my novice eye.

EDIT2: For anyone following the thread Kevin requested the original dump file to see if it jives with the WhatIsHang data. I've sent it off.

[KevinH]

Hi Trane,
DiapDealer was able to get a backtrace from your .dmp file and the error occurs deep inside the Micosoft ole32 and shell32 dlls when creating icons from system file info This could be caused by earlier memory corruption or it could be repeatable. It would help us to know which.

So if it crashes again and you get another (new) .dmp file, would you please zip it up and e-mail it to me at my private e-mail address I pm'd you.

If we get the same backtrace then we can probably rule out memory corruption as the issue and try to figure out why Icon creation in Qt is causing a problem.

Thanks

[Trane]

Originally Posted by KevinH

Hi Trane,
DiapDealer was able to get a backtrace from your .dmp file and the error occurs deep inside the Micosoft ole32 and shell32 dlls when creating icons from system file info This could be caused by earlier memory corruption or it could be repeatable. It would help us to know which.

So if it crashes again and you get another (new) .dmp file, would you please zip it up and e-mail it to me at my private e-mail address I pm'd you.

If we get the same backtrace then we can probably rule out memory corruption as the issue and try to figure out why Icon creation in Qt is causing a problem.

Thanks

Will do and many thanks to both of you for sorting this!

[KevinH]

One other thing you can try if you get a free moment.

Fire up the "Insert Files" dialog and then hit the minus button [-] repeatedly until the thumbnail images go completely away. You will have to look at the preview to see the what the image shows.

Does this stop the crashes?

[Trane]

Originally Posted by KevinH

One other thing you can try if you get a free moment.

Fire up the "Insert Files" dialog and then hit the minus button [-] repeatedly until the thumbnail images go completely away. You will have to look at the preview to see the what the image shows.

Does this stop the crashes?

I sent a couple emails this morning. I updated MS C++ as requested (was just a slightly newer version, both 2015, details in email). So I was just about to open Sigil. Once I get it to crash with the updated C++ files, then I will try turning thumbnails off.

Turning off thumbnails def sounds like it has a VERY good chance of preventing the crashes! But want to get it to crash first, so I can eliminate Sigil "just having a good day" ... as there have been sparse days it hasn't crashed for hours and don't want to sit here wondering if I'm just getting lucky or the solution worked.

That was a great idea! (To turn off thumbnails... didn't know I could and don't need them anyway!)

[Trane]

I had turned thumbnails off when Kevin suggested it to see what he was referring to, though I planned to test with them turned on first. Only I forgot to turn them back on.

So clicked the toolbar icon to insert a picture, the window popped open listing all the image files... (which is when I saw I had left thumbnails off), so clicked the + button 3x to turn thumbnails back on. The file names (fonts) became larger with each click but thumbnails did not appear, then the screen solarized and hung with an instant popup that the program crashed. (I zipped the .dmp and sent it to Kevin.)

So this eliminated updated files as fixing the problem, and as suspected, thumbnails was the key.

THANK YOU KEVIN and DIAPDEALER.

If you guys do find what causes it I hope you will still let this thread know. But it's great it can be prevented so easily by turning thumbnails off. Just to make sure, I will leave them off now and keep testing...

[KevinH]

Interesting. Thanks for the new dmp file. I have passed it on to DiapDealer and so hopefully he will be able to get a backtrace from it.

By studying the current code I have found one potential bug in that drawing the right side Preview window is actually done asynchronously but the current code does not wait for the proper load finished signal from the QWebView.

This can result in reentering the routine that draws that Preview prematurely and that might cause memory corruption. A similar bug was fixed in the ViewEditor code as it caused segfaults in Preview Window and BookView but I fixed that long ago.

I have no idea if this is the root of the problem or not but it certainly can not hurt to fix it to work as it should. I will include these changes into master so that they are fixed in the next release.

BTW: There are many open bug reports at Qt that show almost the exact same backtraces and one hangs indefinitely and one crashes on Windows. Both are related to QFileIconProvider and thumbnails.

For the record, here are two of them that are not closed yet and appear similar to what you are seeing.

https://bugreports.qt.io/browse/QTBUG-45298
https://bugreports.qt.io/browse/QTCREATORBUG-13697?

There are others.

Thanks for sticking this out so we can figure out a way to stop it form happening and improve Sigil.

[Trane]

Originally Posted by KevinH

Interesting. Thanks for the new dmp file. I have passed it on to DiapDealer and so hopefully he will be able to get a backtrace from it.

Thank you.

By studying the current code I have found one potential bug in that drawing the right side Preview window is actually done asynchronously but the current code does not wait for the proper load finished signal from the QWebView.

This can result in reentering the routine that draws that Preview prematurely and that might cause memory corruption. A similar bug was fixed in the ViewEditor code as it caused segfaults in Preview Window and BookView but I fixed that long ago.

I have no idea if this is the root of the problem or not but it certainly can not hurt to fix it to work as it should. I will include these changes into master so that they are fixed in the next release.

I have no knowledge of programming but just from what you're saying that actually sounds like it could be the problem...

Thanks for sticking this out so we can figure out a way to stop it form happening and improve Sigil.

Thank YOU and DiapDealer for sticking it out. I am sorry I have been under the gun and wasn't able to do this back when you first mentioned collecting bug reports from Windows (like halfway through this thread). I had to take so much time away from working (for my friend who's ill) I just got really slammed time-wise.

I'm really looking forward to seeing what it turns out to be, and super happy I have a way around it. (EDIT: And so far no more crashes!)

[Trane]

Sigil reacts so much better with thumbnails off. The file insertion window opens near-instantly and everything has been running like clockwork now for a few hours... I can tell it's not going to crash. YAY!!!

[KevinH]

Okay your second dmp backtrace was virtually identical to your first one. So I doubt this is memory corruption related at all.

I have dug through the code and I am convinced this is not caused by Sigil doing anything wrong. It seems that shell and ole dll's have issues creating icons from certain paths when run in separate threads. So I think the problem is an internal Qt problem in the Qt Windows theme code.

There are newer bug reports against even Qt 5.8.0 showing issues with QFileIconProvider and QPixmap when passed a file path but only on Windows. Something to do with the file size or requested icon size or the existence of dangling drive letters that point to nothing ends up killing SHGetFileInfoW() which is what the backtrace shows as well.

Given we know that the file paths exist inside the epub and that each image can actually be loaded into the Preview, then it must be something else that is messing with things.

So I have added the code to handle asynchronous resource loading in a QWebView to make sure Sigil's code is up to snuff.

I have also changed the use of QPixmap operating on a file path (the code path that results in a segfault) to actually operate on a QImage of that filepath instead (since we know they are image files) to create the thumbnails.

Hopefully this will allow us to work around the Qt bug until we can figure out something more.

I am glad your workaround of hiding the thumbnails helped.

When, the next release comes out, would you be willing to try it and reenable the thumbnails to try and see if our changes did the trick or not?

Thanks for your bug report.

KevinH

[Trane]

Kevin, thanks so much for that detailed update. While I am not a programmer it's interesting to hear the summation and I do get the gist. It will be interesting to see if the new Sigil code works around the Qt bug. Of course I would be happy to test the new release when available.

Will the new release be on the normal Sigil update site, or will this be a beta I should look for elsewhere? Any inkling at all of the timeline on when I might find it available? (I'll be setting a Stickie to remind myself to check for it every few days, as if it won't be available soon I might have moved beyond the Sigil-related stage of this project.)

I will use the same project for testing, going through the same motions. Just to make sure nothing on my end changes.

BTW I worked placing more images last night for several hours with nary a problem. Disabling thumbnails DEF eliminates the processes that cause the problem. It also makes the insert file window pop open much faster. This entire thing was worth it for that alone. Even once it's fixed I will be leaving thumbnails off, myself. (Then again this project has 155 images associated with it. It would probably open thumbnails much faster with a normal project using a handful of images.)

Again, many thanks, Kevin!

[DiapDealer]

Originally Posted by Trane

Will the new release be on the normal Sigil update site, or will this be a beta I should look for elsewhere? Any inkling at all of the timeline on when I might find it available?

This will likely be a beta. I hope to be able to get a build with the proposed changes in it ready by today or tomorrow at the latest. If you don't mind, I'll send you a PM with a link where you can download it from when I have it ready.

[Trane]

Originally Posted by DiapDealer

This will likely be a beta. I hope to be able to get a build with the proposed changes in it ready by today or tomorrow at the latest. If you don't mind, I'll send you a PM with a link where you can download it from when I have it ready.

Thank you DiapDealer.... and for all your work. (I know you are doing it for the Sigil community and not me personally, but I still thank you.) I will start testing as soon as I see the PM... I know it helps to follow through in a timely manner so everything is fresh in your mind...

[exaltedwombat]

Originally Posted by Trane

I only go into SafeMode upon threat of death. It screws all my desktop icons up.

Goodness! However many have you got?

[Trane]

Originally Posted by exaltedwombat

Goodness! However many have you got?

52. But 9 will be deleted when I am done with this project. Many are shortcuts to folders, many are shortcuts to programs I use often [but not often enough to put in QuickLaunch], others are shortcuts to tools I use (e.g. DeviceMgr), and still others are shortcuts to files I use daily. Each is in its rightful place (not on a grid) and when I go into SafeMode it takes 20 freakin minutes to put them all back where they belong. Needless to say, I never go into SafeMode. Thankfully though, I never have to.