Bug 491701

Hi, Bugalt!

tldr; please attach the %localappdata%\krita-sysinfo.log and  %localappdata%\krita.log files to the bugreport and try to switch between Angle and OpenGL renderers.

The topic of memory consumption is really complicated. The amount of memory limit one sets in the preferences is related only to actual "image data" used in Krita, i.e. layers, projections and so on. On the top of that, Krita has a lot "not-accounted" memory, like opengl textures, transfer buffers, animation cache and so on. It means that the amount of memory actually consumed by Krita will always be higher than set in the preferences. And the slider in the status bar gives only a rough estimation of the memory that the image consumes. It is intentionally made rather pessimistic, i.e. it almost always shows higher values than image consumes on real hardware. Just for the sake of efficiency.

Could you answer a few questions for me:

1) Does your image has animation?
2) Do you use 'on-disk-frames-cache' or 'in-memory-frame-cache'? (Preferences->Performance->Animation)
3) What are the dimensions of the image (and the amount of frames if it is animated)?

The backtrace looks rather weird. It shows that Krita crashes in some openGL-related code. Which might be caused by a real out-of-memory condition or just some other unrelated bug.

Mark as needsinfo

The backtrace actually points to this piece of code:

template <typename T>
    T *value(QOpenGLContext *context) {
        QOpenGLContextGroup *group = context->shareGroup();
        // Have to use our own mutex here, not the group's, since
        // m_groups has to be protected too against any concurrent access.
        QMutexLocker locker(&m_mutex);
        T *resource = static_cast<T *>(group->d_func()->m_resources.value(this, 0));
        if (!resource) {
            resource = new T(context);
            insert(context, resource);
        }
        return resource;
    }

It tries to dereference a pointer with value 0x08, which basically means that either `context` is null or its shared group (`group`) is null. I don't know why it could happen, but it does not look like it is a OOM issue.

Created attachment 172621 [details]
krita-sysinfo.log and krita.log files (concatenated)

Sessions created today (Aug 14) in krita.log were for the purposes of collecting information for this bug report (I accidentally closed the application once, which is why two sessions are recorded).

1) None of my images contain animations.
2) Settings -> Configure Krita -> Performance -> Animation Cache is set to On-disk (with Cache Generation Options: Limit cached frame size: 2500 px, Use region of interest: 25%, and Enable background cache generation, all enabled).
3) Of the two images I have been editing over the past few days, one was 2,100 x 1,900 ("blue dress..." .kra) and the other was 2,000 x 2,000 ("asian lips..." .kra). I made several manual backups of each file during the process of drawing them.

🐛🧹 Thanks for your comment!

Automatically switching the status to REPORTED so the team can perform further triage.

In the future you may also do this yourself when providing needed information.

Created attachment 172844 [details]
New information since previous krita.log

I have been (and continue to be) very busy, however, I felt it necessary to mention that I gathered some new information during the previous week. Specifically - after switching to the OpenGL renderer, I experienced no issues related to Krita, over the span of multiple hours-long sessions over multiple days. I should note that during nearly all of my newer sessions, I was editing a different (new) file than the ones I had been editing previously (in my initial crash report). Also, all references to memory/RAM usage in the following comment are referring to the program (Krita)'s RAM usage as shown by the Windows Task Manager; not Krita's built-in memory footer.

After switching back to ANGLE (the default) again, I had another instance of exponentially increasing RAM usage, followed by a soft-crash, where the canvas and most of the editor itself did not respond or refresh despite my inputs, causing the program to be unusable, and requiring me to close the program myself and restart it (after which it functioned normally again).

Over several sessions and multiple days, I monitored the RAM usage rates when OpenGL or ANGLE were selected to get an idea of a typical usage rate for each of them. For OpenGL, I believe the number was between 200-700 megabytes, and never exceeded 1 gigabyte (at least, for the file I was editing). For ANGLE, the number was somewhere around the 0.7-1.5 gigabytes range, on average (which is entirely acceptable). There was one exception, however (explained below).

When Krita soft-crashed this time (while using the ANGLE renderer, same as my original crash report), I had been observing Krita's RAM usage using Windows' Resource Monitor over time (prior to it soft-crashing) and noticed it had been strangely increasing in RAM despite the file being edited not having very major changes made to it during the same timeframe; nor did RAM usage ever increase in a similar manner when the OpenGL renderer was selected instead of ANGLE. During the soft-crash, Krita had reached over 8 gigabytes of working memory. As before, and as you've mentioned, I am unsure if memory is at all related to the crashes, but it appeared to be abnormal, and coincided almost perfectly with several of the aforementioned crashes as well, so I am including it as it may be potentially insightful.

Because the program did not hard crash, and was manually closed by me instead, my kritacrash.log file did not update to include any new crash information compared to the one I already uploaded. The soft-crash occurred sometime around 2:00 PM (14:00) on August 17th. I have a recording of it which showed its symptoms and Resource Monitor usage as it was occurring, however, I have not yet edited my personal information (which was accidentally displayed on-screen) out of the recording yet, and the recording also contains potentially offensive content (a cartoon character dead by hanging, drawn as part of a comic). If such a recording would be both potentially useful and acceptable for me to upload as an attachment (after I find the time to remove my personal information from it) please let me know, and I could upload it.

If it's the difference between angle and opengl, then I would suspect it's a gpu driver issue -- but that doesn't mesh with the crash log which shows an issue inside Qt itself, when it tries to multi-thread.

This is troubling, we cannot confirm the issue because we don't have a way to reproduce it, and I'm not sure whether there is actually more information.