[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2020-02-03 Thread Wood
https://bugs.kde.org/show_bug.cgi?id=410767

Wood  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Wood  ---
Crash stopped happening in 5.4.x > 5.4.0.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-18 Thread Wood
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #9 from Wood  ---
(In reply to Wood from comment #8)
> (In reply to Friedrich W. H. Kossebau from comment #7)
> > I would be interested in the value of the QModelIndex arguments passed to
> > QAbstractProxyModel::data and even more the one passed to
> > QuickOpenModel::data. The r & c member values are of most interest to me.
> > 
> > Looking around at the code I found a possible code path which might lead to
> > bogus ActionsQuickOpenItem objects due to out-of-bounds array access. But
> > not sure yet how it could be reached or rather triggered from the backtrace,
> > having the values of those QModelIndex arguments would at least prove that
> > code path is reached here.
> > 
> > Still no idea why the quickopen code is run here at all. The
> > QCoreApplicationPrivate::sendThroughObjectEventFilters might give a hint
> > though,  perhaps something is broken in the logic of QuickOpenLineEdit which
> > does a
> > qApp->installEventFilter(this);
> > call though tries to unregister when not active...
> 
> Unfortunately I lost the coredump file (got cleaned-up automatically this
> weekend).

Crashed again, very similar call stack. The lack of debug symbols makes it hard
to figure out what r and c are in the index param passed to
QuickOpenModel::data. But I'm pretty sure the c was 1 and the "role" paramter
is Qt::DecorationRole. I couldn't figure out the value of r(In reply to Wood
from comment #8)
> (In reply to Friedrich W. H. Kossebau from comment #7)
> > I would be interested in the value of the QModelIndex arguments passed to
> > QAbstractProxyModel::data and even more the one passed to
> > QuickOpenModel::data. The r & c member values are of most interest to me.
> > 
> > Looking around at the code I found a possible code path which might lead to
> > bogus ActionsQuickOpenItem objects due to out-of-bounds array access. But
> > not sure yet how it could be reached or rather triggered from the backtrace,
> > having the values of those QModelIndex arguments would at least prove that
> > code path is reached here.
> > 
> > Still no idea why the quickopen code is run here at all. The
> > QCoreApplicationPrivate::sendThroughObjectEventFilters might give a hint
> > though,  perhaps something is broken in the logic of QuickOpenLineEdit which
> > does a
> > qApp->installEventFilter(this);
> > call though tries to unregister when not active...
> 
> Unfortunately I lost the coredump file (got cleaned-up automatically this
> weekend).

Crashed again, very similar call stack. The lack of debug symbols makes it hard
to figure out what r and c are in the index param passed to
QuickOpenModel::data. But I'm pretty sure the c was 1 and the "role" paramter
is Qt::DecorationRole. I couldn't figure out the value of r

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-12 Thread Wood
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #8 from Wood  ---
(In reply to Friedrich W. H. Kossebau from comment #7)
> I would be interested in the value of the QModelIndex arguments passed to
> QAbstractProxyModel::data and even more the one passed to
> QuickOpenModel::data. The r & c member values are of most interest to me.
> 
> Looking around at the code I found a possible code path which might lead to
> bogus ActionsQuickOpenItem objects due to out-of-bounds array access. But
> not sure yet how it could be reached or rather triggered from the backtrace,
> having the values of those QModelIndex arguments would at least prove that
> code path is reached here.
> 
> Still no idea why the quickopen code is run here at all. The
> QCoreApplicationPrivate::sendThroughObjectEventFilters might give a hint
> though,  perhaps something is broken in the logic of QuickOpenLineEdit which
> does a
> qApp->installEventFilter(this);
> call though tries to unregister when not active...

Unfortunately I lost the coredump file (got cleaned-up automatically this
weekend).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-12 Thread Friedrich W. H. Kossebau
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #7 from Friedrich W. H. Kossebau  ---
I would be interested in the value of the QModelIndex arguments passed to
QAbstractProxyModel::data and even more the one passed to QuickOpenModel::data.
The r & c member values are of most interest to me.

Looking around at the code I found a possible code path which might lead to
bogus ActionsQuickOpenItem objects due to out-of-bounds array access. But not
sure yet how it could be reached or rather triggered from the backtrace, having
the values of those QModelIndex arguments would at least prove that code path
is reached here.

Still no idea why the quickopen code is run here at all. The
QCoreApplicationPrivate::sendThroughObjectEventFilters might give a hint
though,  perhaps something is broken in the logic of QuickOpenLineEdit which
does a
qApp->installEventFilter(this);
call though tries to unregister when not active...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-12 Thread Friedrich W. H. Kossebau
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #6 from Friedrich W. H. Kossebau  ---
(In reply to David Redondo from comment #5)
> This happens not only in the Appimage. Just hit this when using the neon
> package.

Same backtrace? Do you remember what you did?

The best idea I have so far is that QuickOpenModel::data() does not protect
against being called with an invalid index (here coming from direct mapping
call from QAbstractProxyModel), or rather QuickOpenModel::getItem not against
being called with row == -1, where it would return a out-of-array-bounds item
for ActionsQuickOpenProvider then. Though only if that provider is first in the
list, where it gets added as last and would be only first if all the othes are
disabled...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-12 Thread David Redondo
https://bugs.kde.org/show_bug.cgi?id=410767

David Redondo  changed:

   What|Removed |Added

 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1
 CC||k...@david-redondo.de

--- Comment #5 from David Redondo  ---
This happens not only in the Appimage. Just hit this when using the neon
package.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-09 Thread Friedrich W. H. Kossebau
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #4 from Friedrich W. H. Kossebau  ---
(In reply to Wood from comment #3)
> just in case it helps, I poked around a little bit in gdb at the
> disassembled code and indeed ActionsQuickOpenItem::m_action value looks like
> a horked pointer: 0x4090

Interesting, that would rather hint the ActionsQuickOpenItem struct itself is
bogus, as the m_action is set in the constructor (where it should be a proper
pointer value)  and never changed later. Something to look out for as well.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-09 Thread Wood
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #3 from Wood  ---
(In reply to Friedrich W. H. Kossebau from comment #1)
> Thanks for the report. Never seen before. Can you remember what you exactly
> did? What language do you develop with? Did you enable/disable plugins?
> 
> Developer notes:
> Backtrace possibly hints to a QAction accessed which no longer exists. The
> QAction pointed to by ActionsQuickOpenItem is added during a filtering run,
> where ActionsQuickOpenProvider::setFilterText() queries
> KActionCollection::allCollections() for all actions. But there is no
> mechanism to catch actions being deleted at a later point, while the item is
> still existing.
> 
> The rest of the backtrace hints that the popup of the QuickOpen menu is
> triggered, and possibly at that point it still holds the results of the last
> search.
> 
> Needs more investigation.

just in case it helps, I poked around a little bit in gdb at the disassembled
code and indeed ActionsQuickOpenItem::m_action value looks like a horked
pointer: 0x4090

Dump of assembler code for function _ZNK7QAction4iconEv:
   0x7f2d92c46510 <+0>: push   rbx
   0x7f2d92c46511 <+1>: movrsi,QWORD PTR [rsi+0x8]
   0x7f2d92c46515 <+5>: movrbx,rdi
   0x7f2d92c46518 <+8>: addrsi,0x90
   0x7f2d92c4651f <+15>:call   0x7f2d92c3c780 
=> 0x7f2d92c46524 <+20>:movrax,rbx


(gdb) info registers
rax0x1  1
rbx0x7ffe08c73b00   140729045695232
rcx0xca89030212373552
rdx0x188607a0   411436960
rsi0x4090   4611686018427388048
rdi0x7ffe08c73b00   140729045695232
rbp0x7ffe08c73b70   0x7ffe08c73b70
rsp0x7ffe08c73b00   0x7ffe08c73b00
r8 0x7f01fec0   2130837184
r9 0x83 131
r100x   4294967295
r110x0  0
r120x171e9fd0   387882960
r130x7ffe08c73bd0   140729045695440
r140x2a529d044378576
r150x1  1
rip0x7f2d734b3e69   0x7f2d734b3e69 
eflags 0x206[ PF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-09 Thread Wood
https://bugs.kde.org/show_bug.cgi?id=410767

--- Comment #2 from Wood  ---
(In reply to Friedrich W. H. Kossebau from comment #1)
> Thanks for the report. Never seen before. Can you remember what you exactly
> did? What language do you develop with? Did you enable/disable plugins?
> 
> Developer notes:
> Backtrace possibly hints to a QAction accessed which no longer exists. The
> QAction pointed to by ActionsQuickOpenItem is added during a filtering run,
> where ActionsQuickOpenProvider::setFilterText() queries
> KActionCollection::allCollections() for all actions. But there is no
> mechanism to catch actions being deleted at a later point, while the item is
> still existing.
> 
> The rest of the backtrace hints that the popup of the QuickOpen menu is
> triggered, and possibly at that point it still holds the results of the last
> search.
> 
> Needs more investigation.

The codebase I was editing is C++. Just before the crash, I pasted two lines of
template code in a .h file.

The weird thing is that in the callstack I saw references to quickopen which
you also mentioned, but I'm pretty sure I was not trying to use the quick open
box. The mouse pointer was hovering somewhere near the new pasted lines in the
editor panel and I didn't hit any of the shortcuts for the quick open actions.

I have some plugins disabled: svn, perforce, bazaar, ninja, meson, ctags, man
pages

The core file is unfortunately not very helpful, there are no debug symbols

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 410767] Crash 5.4.0 appimage

2019-08-09 Thread Friedrich W. H. Kossebau
https://bugs.kde.org/show_bug.cgi?id=410767

Friedrich W. H. Kossebau  changed:

   What|Removed |Added

 CC||kosse...@kde.org

--- Comment #1 from Friedrich W. H. Kossebau  ---
Thanks for the report. Never seen before. Can you remember what you exactly
did? What language do you develop with? Did you enable/disable plugins?

Developer notes:
Backtrace possibly hints to a QAction accessed which no longer exists. The
QAction pointed to by ActionsQuickOpenItem is added during a filtering run,
where ActionsQuickOpenProvider::setFilterText() queries
KActionCollection::allCollections() for all actions. But there is no mechanism
to catch actions being deleted at a later point, while the item is still
existing.

The rest of the backtrace hints that the popup of the QuickOpen menu is
triggered, and possibly at that point it still holds the results of the last
search.

Needs more investigation.

-- 
You are receiving this mail because:
You are watching all bug changes.