Memory Leak? (v2.31)

[hayaku]

Hello.

I must admit, I wouldn't have expected that my RTX4090 would ram out running, Sigil, but it seems to be the case with v2.31



Is this memory leak documented, with a fix on the way?

Sometimes, I've come back home to find Sigil consuming >20GB of VRAM. Quite concerning!

Thanks for this app, keep up the good work everybody!

[DiapDealer]

It's always possible. A successful Windows QtWebEngine compilation nearly always has warnings of potential memory leaks. But the Qt used with Sigil 2.3.1 is the same one used with Sigil 2.3.0, so I would expect identical results. Any info on just how long Sigil had to stay running to get to the numbers you screen capped?

For the record... Sigil almost never needs very much GPU for rendering epubs. That's why we added the ability to turn off WebEngine's hardware acceleration in Sigil's preferences: to handle the edge cases where WebEngine doesn't always play nice with certain video cards. Have you tried disabling that?

[DiapDealer]

I'm not one to leave programs open and running for days at a time, but I'll leave Sigil running to see if I can duplicate your results. So far, my dedicated gpu memory is fluctuating between 0 and around 7,000K. But it's early. I'll keep checking.

[KevinH]

There is a bug posted to Qt about memory consumption with some AMD processors. I do not have a link handy but there are known issues.

I think I found the Qt bug report:

https://bugreports.qt.io/browse/QTBUG-125747

Using the --disable-gpu flag seemed to fix things. This did not happen with Intel.

[DiapDealer]

I'm testing on an AMD processor at home right now. But I'm away from it, so I'll have to report back later.

On the Intel laptop (integrated GPU) that I'm also testing on, all memory usage increases with use, but seems to settle back down to numbers that match what it launched with after some idle time. So no net increase that I've been able to find so far.

[DiapDealer]

It's not exactly the same as the OP's experience, but I'm seeing some strange results even on my Intel laptop with integrated GPU. When showing my shared GPU memory usage, I can make it steadily increase by simply minimizing and restoring Sigil over and over again. I got it up over a gigabyte and while it eventually went down a little, it never fully recovered (not even close).

This is all with the empty, default Sigil epub.

When I check the "Disable GPU Acceleration in QtWebEngine (in Sigil preferences), this behavior stops completely. The shared GPU memory usage stays nearly constant no matter how much minimizing and restoring I do.

Regular RAM usage stays fairly constant regardless of all of this.

[KevinH]

This is exactly what happened with the macOS memory leak Qt fixed earlier (but the fix was only for Apple Metal graphics). There was even a qml example program that opened a QtWebEngine WebEngineView and just constantly resized it, and you could watch the memory use just grow.

I will see if I can find the qml sample program and Qt bug.

Update: See https://bugreports.qt.io/browse/QTBUG-124353

In that issue is a bug.qml test case that you can run with the command:

qml bug.qml

and just watch the memory consumption grow due to huge memory leak. On arm64 mac the gpu and main memory s shared and you can see the gpu memory just grow.

It was fixed for MacOS in qt 6.7 with a patch.

Perhaps something similar is happening on Windows or Linux.

[hayaku]

Hello all, thanks for the replies & interest!

Processor is an AMD 7950X in case anybody is wondering, or if that makes any difference.

It's hard to say how long I've left Sigil open to get this issue, but would be in the order of 24–48h.

I work within Sigil as my main text editing/writing platform (call me a masochist, but I really love it). So it stays open by default, 24/7 unless I need to restart my computer for any kind of reason.

@KevinH thanks for the additional info!

[DiapDealer]

Are you able to determine if turning off QtWebEngine's hardware acceleration in Sigil's preferences eliminates the problem or not?

[hayaku]

Ok, now we are up to 24 GB of VRAM used, only since this morning!

I've just disabled GPU Acceleration, but I switched it straight back on again. Taking it off made Sigil run like garbage, clunky like you wouldn't believe

[hayaku]

OK, I just did some experimenting.

I was able to get Sigil to go from about ~200MB of Memory use, up to >50 GB of memory use, in about 30 seconds.

All I had to do was grab the boundary for the "Preview Window" and resize it about 20 times, through click-and-drag.

Obviously, this would have maxed out my 4090, and then spilled over into my RAM to get this high.

Whose responsibility is this? Can we make a bug report and have it patched by the same people who fixed the Mac version, as already indicated?

[DiapDealer]

Originally Posted by hayaku

I've just disabled GPU Acceleration, but I switched it straight back on again. Taking it off made Sigil run like garbage, clunky like you wouldn't believe

That makes no sense to me. I've never noticed any performance difference whatsoever when disabling hardware acceleration for QtWebEngine in Sigil's preferences. No hardware acceleration is needed for rendering epubs with Sigil. The only thing disabling it could possibly affect in terms of performance is the Preview Window. And as mentioned, I've never witnessed any performance hit in that regard.

Something is very strange here if disabling that setting on modern hardware is affecting Sigil's overall performance.

Why is Sigil is using dedicated GPU RAM on your machine in the first place? It shouldn't need any of your GPU. Do you have something installed that forces programs to use dedicated GPU Ram? I've only ever seen Sigil use shared GPU Ram (with integrated GPUs).

Your Sigil experience is unlike any I've seen myself, or heard from other users.

[DiapDealer]

Are you testing with Sigil's default empty epub, or an epub of your own? I'm asking because I'm trying to determine if the epub itself might not exacerbating the issue. Giant epubs (especially ones with very long/giant xhtml files with tons of images) can cause Sigil performance issues in general.