Bug 443741

Summary: Weird crash in Overview docker
Product: [Applications] krita Reporter: Tiar <tamtamy.tymona>
Component: DockersAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED WORKSFORME    
Severity: crash    
Priority: NOR    
Version First Reported In: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Crashlog
krita.opengl debugging output option

Description Tiar 2021-10-14 19:50:15 UTC
Created attachment 142445 [details]
Crashlog

SUMMARY
I opened a new image to test something (image was 3840x2160), and the crash happened either on opening, or maybe on closing, or on zooming in/out, or maybe panning. I'm not sure because I only noticed that it crashed when I noticed it doesn't respond to my zooming or panning. I might've tried to delete it, even, though I doubt it.

STEPS TO REPRODUCE
1. I don't know how to reproduce

SOFTWARE/OS VERSIONS
Krita

 Version: 5.1.0-prealpha (git 45ea10672e - and a few commits from MR !1090)
 Languages: en_US, en, en_US, en, en_US, en, pl_PL, pl, pl_PL, pl
 Hidpi: true

Qt

  Version (compiled): 5.11.1
  Version (loaded): 5.11.1

-----
Backtrace and a bit of log at the beginning:

i965: Failed to submit batchbuffer: Błędny adres [English: wrong/incorrect address]
i965: Failed to submit batchbuffer: Błędny adres

Thread 51 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff797fa700 (LWP 30454)]
0x00007ffff7191039 in KisTransformWorker::transformPass<KisSharedPtr<KisHLineIteratorNG> > (this=this@entry=0x7fff797f9c00, src=0x7fff84003370, dst=0x7fff84003370, floatscale=0.5, shear=0, dx=0, filterStrategy=0x555561835550, 
    portion=portion@entry=50) at /home/tymon/kritadev/krita/libs/image/kis_filter_weights_applicator.h:144
144	        LinePos(int start, int size)
(gdb) bt
#0  0x00007ffff7191039 in KisTransformWorker::transformPass<KisSharedPtr<KisHLineIteratorNG> >(KisPaintDevice*, KisPaintDevice*, double, double, double, KisFilterStrategy*, int) (this=this@entry=0x7fff797f9c00, src=0x7fff84003370, dst=0x7fff84003370, floatscale=0.5, shear=0, dx=0, filterStrategy=0x555561835550, portion=portion@entry=50) at /home/tymon/kritadev/krita/libs/image/kis_filter_weights_applicator.h:144
#1  0x00007ffff718fbeb in KisTransformWorker::runPartial(QRect const&) (this=0x7fff797f9c00, processRect=...) at /home/tymon/kritadev/krita/libs/image/kis_transform_worker.cc:354
#2  0x00007ffff719051f in KisTransformWorker::run() (this=0x7fff797f9c00) at /home/tymon/kritadev/krita/libs/global/kis_shared_ptr.h:167
#3  0x00007fffd82acc78 in OverviewThumbnailStrokeStrategy::finishStrokeCallback() (this=0x55555c71e7f0) at /home/tymon/kritadev/krita/plugins/dockers/overview/OverviewThumbnailStrokeStrategy.cpp:123
#4  0x00007ffff6e51e03 in non-virtual thunk to KisUpdateJobItem::run() () at /usr/include/x86_64-linux-gnu/qt5/QtCore/qdebug.h:125
#5  0x00007ffff59e6f71 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff59eec87 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007ffff34e9182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#8  0x00007ffff5661b1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Comment 1 Tiar 2021-10-14 19:53:20 UTC
It looks a bit similar like in bug 443347 except that it only had one layer, the background layer. It was unlocked.

@Dmitry, does it look like something that was caused by a transform tool changes? If yes, please add the "regression" and "release_blocker" tags as well so it isn't lost.
Comment 2 Dmitry Kazakov 2021-11-16 10:19:57 UTC
The backtrace looks as if stack pointer got smashed, though I don't know how it could happen...
Comment 3 Dmitry Kazakov 2021-11-16 11:13:15 UTC
Hi, Tiar!

I looked into the backtrace and it looks like the transform tool in not actually the cause of the error. The error comes from the Intel's openGL driver. The sequence of events is like that:

1) We ask for a GLSync object in GUI thread:

#60 0x00007ffff79e1277 in Sync::getSync() () at /home/tymon/kritadev/krita/libs/ui/opengl/KisOpenGLSync.cpp:72

2) Intel openGL driver panics and calls GI_exit, which starts destruction of all the static objects including KisPart (and all the documents)

3) KisPart tries to open a busy wait dialog to wit until the transformation is finished:

#45 0x00007ffff7824bdd in KisDelayedSaveDialog::blockIfImageIsBusy() (this=0x7fffffffacd0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:120
#46 0x00007ffff7c88166 in (anonymous namespace)::busyWaitWithFeedback(KisSharedPtr<KisImage>) (image=...) at /home/tymon/kritadev/krita/libs/ui/KisPart.cpp:126

4) The dialog opens and asks Intel driver to draw the window :)

#11 0x00007ffff558b2ac in __run_exit_handlers (status=1, listp=0x7ffff5728718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#12 0x00007ffff558b3da in __GI_exit (status=<optimized out>) at exit.c:139
#13 0x00007fffe2353fa3 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#14 0x00007fffe2333434 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#15 0x00007ffff65b4223 in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007ffff6581ca5 in QWidgetPrivate::sendComposeStatus(QWidget*, bool) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

5) The driver freaks out (it has declared itself as dead long before) and calls GI_exit once again, which starts the second round of freeing all the static objects (some of them has already been free'd obviously). It corrupts the memory, making the transform worker fail on trivial thing.

So, I believe, this bug is either not In Krita or in the way how Krita uses GLSync. Can you debug what happens inside KisOpenGLSync and whether there is something suspicious happens?

Basically, it would be interesting to know if these functions behave in an expected way:

k_glFenceSync  = (kis_glFenceSync)ctx->getProcAddress("glFenceSync");
k_glGetSynciv  = (kis_glGetSynciv)ctx->getProcAddress("glGetSynciv");
k_glClientWaitSync = (kis_glClientWaitSync)ctx->getProcAddress("glClientWaitSync")
Comment 4 Tiar 2021-12-01 13:56:22 UTC
Created attachment 144115 [details]
krita.opengl debugging output option

Not sure if helpful, but this is what showed up when I started Krita with "krita.opengl" debugging output option.
Comment 5 Dmitry Kazakov 2021-12-01 14:13:00 UTC
The backtrace points deep into the internals of the GPU driver, so there are two possibilities: 1) the bug is in the driver; 2) we had some memory corruption. We have fixed a memory corruption quite recently in bug 444516. So let's close this bug either as "bug-in-the-driver" or "duplicate".