https://bugs.kde.org/show_bug.cgi?id=438097
--- Comment #18 from Ash Blake <telepath...@tutanota.com> ---
I didn't get a crash so far, but I revisited the previous coredump, as it seems
weird that the EffectWindow was at least a bit intact this time.
Disassembly of the current instruction and the one before it:
0x7fb16c02e4c2 <...postPaintScreenEv+1682> mov (%rdi),%rax
> 0x7fb16c02e4c5 <...postPaintScreenEv+1685> call *0x90(%rax)
The RDI register contained the address of the EffectWindow, same as in
entry.key
EffectWindow::addLayerRepaint is virtual, so the address of the actual function
EffectWindowImpl::addLayerRepaint has to be read from the vtable.
(In this case) the first few bytes of EffectWindow should contain a vtable ptr,
which is then read into RAX by 'mov (%rdi),%rax'.
The EffectWindowImpl::addLayerRepaint function pointer is then expected to
exist at RAX + 0x90.
It looks like the vtable pointer points to an invalid location:
(gdb) p/x $rax
$23 = 0x55f806f2e
(gdb) x/x $rax
0x55f806f2e: Cannot access memory at address 0x55f806f2e
And vtable+0x90 is also unreadable:
(gdb) x/x $rax+0x90
0x55f806fbe: Cannot access memory at address 0x55f806fbe
In the coredump from yesterday, the situation is the same:
0x7f9fafd984c2 <...postPaintScreenEv+1682> mov (%rdi),%rax
> 0x7f9fafd984c5 <...postPaintScreenEv+1685> call *0x90(%rax)
(gdb) p/x $rax
$1 = 0x55f06b86305a
(gdb) x/x $rax
0x55f06b86305a: Cannot access memory at address 0x55f06b86305a
(gdb) x/x $rax+0x90
0x55f06b8630ea: Cannot access memory at address 0x55f06b8630ea
Yesterday the EffectWindow was destroyed completely, and the member variables
looked pretty much random.
In today's crash it seems like the EffectWindow was in the process of getting
deleted, as some of the member variables looked intact. The vtable however
already got corrupted, which made the call result in a segfault.
--
You are receiving this mail because:
You are watching all bug changes.
