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.

(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

(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: 0x4000000000000090

Dump of assembler code for function _ZNK7QAction4iconEv:
   0x00007f2d92c46510 <+0>:     push   rbx
   0x00007f2d92c46511 <+1>:     mov    rsi,QWORD PTR [rsi+0x8]
   0x00007f2d92c46515 <+5>:     mov    rbx,rdi
   0x00007f2d92c46518 <+8>:     add    rsi,0x90
   0x00007f2d92c4651f <+15>:    call   0x7f2d92c3c780 <QIcon::QIcon(QIcon const&)@plt>
=> 0x00007f2d92c46524 <+20>:    mov    rax,rbx


(gdb) info registers
rax            0x1      1
rbx            0x7ffe08c73b00   140729045695232
rcx            0xca89030        212373552
rdx            0x188607a0       411436960
rsi            0x4000000000000090       4611686018427388048
rdi            0x7ffe08c73b00   140729045695232
rbp            0x7ffe08c73b70   0x7ffe08c73b70
rsp            0x7ffe08c73b00   0x7ffe08c73b00
r8             0x7f01fec0       2130837184
r9             0x83     131
r10            0xffffffff       4294967295
r11            0x0      0
r12            0x171e9fd0       387882960
r13            0x7ffe08c73bd0   140729045695440
r14            0x2a529d0        44378576
r15            0x1      1
rip            0x7f2d734b3e69   0x7f2d734b3e69 <ActionsQuickOpenItem::icon() const+41>
eflags         0x206    [ PF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

(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: 0x4000000000000090

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.

This happens not only in the Appimage. Just hit this when using the neon package.

(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...

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...

(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).

(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

Crash stopped happening in 5.4.x > 5.4.0.