Can you post or attach the backtrace of a core dump?

Igor Kushnir wrote on 8/10/23 12:54:
> https://bugs.kde.org/show_bug.cgi?id=473251
> 
> Igor Kushnir <igorkuo@gmail.com> changed:
> 
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |igorkuo@gmail.com
> 
> --- Comment #1 from Igor Kushnir <igorkuo@gmail.com> ---
> Can you post or attach the backtrace of a core dump?
> 

Is this what you want me to do?

----

n7dr@shack20:~/projects/drlog/build-debug$ gdb /usr/bin/kdevelop core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/kdevelop...
(No debugging symbols found in /usr/bin/kdevelop)
[New LWP 1876]
[New LWP 1878]
[New LWP 1902]
[New LWP 1883]
[New LWP 1877]
[New LWP 1885]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `kdevelop'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (threadid=<optimized out>, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
[Current thread is 1 (Thread 0x7f10b613ba40 (LWP 1876))]
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x00007f10c12a9d9f in __pthread_kill_internal (signo=6, 
threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007f10c125af32 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x00007f10c12454fc in __GI_abort () at ./stdlib/abort.c:100
#4  0x00007f10c129e340 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f10c13b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x00007f10c12b36ba in malloc_printerr (str=str@entry=0x7f10c13bb158 
"double free or corruption (!prev)") at ./malloc/malloc.c:5660
#6  0x00007f10c12b572c in _int_free (av=0x7f10c13f1c60 <main_arena>, 
p=0x563fd3936c00, have_lock=<optimized out>, have_lock@entry=0) at 
./malloc/malloc.c:4587
#7  0x00007f10c12b7d9f in __GI___libc_free (mem=<optimized out>) at 
./malloc/malloc.c:3385
#8  0x00007f10c1b0cc20 in QAccessibleCache::~QAccessibleCache() () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x00007f10c1b0cda8 in ?? () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#10 0x00007f10c16b3762 in qt_call_post_routines() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f10c2363664 in QApplication::~QApplication() () from 
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x0000563fd03812c3 in ?? ()
#13 0x00007f10c12461ca in __libc_start_call_main 
(main=main@entry=0x563fd037dcc0, argc=argc@entry=1, 
argv=argv@entry=0x7fff0b77d708) at ../sysdeps/nptl/libc_start_call_main.h:58
#14 0x00007f10c1246285 in __libc_start_main_impl (main=0x563fd037dcc0, argc=1, 
argv=0x7fff0b77d708, init=<optimized out>, fini=<optimized out>, 
rtld_fini=<optimized out>, stack_end=0x7fff0b77d6f8) at ../csu/libc-start.c:360
#15 0x0000563fd0383281 in ?? ()
(gdb)

----

   Doc

(In reply to doc.evans from comment #2)
> Is this what you want me to do?
Yes, thank you.
> #8  0x00007f10c1b0cc20 in QAccessibleCache::~QAccessibleCache() () from 
> /lib/x86_64-linux-gnu/libQt5Gui.so.5
This crash on exit could be related to Bug 472891 that you recently reported. There could be a bug in Qt accessibility support or KDevelop's (indirect) usage of it.

The error messages have different causes. Some of them are probably not KDevelop's fault, but something's wrong on your system.
The kdevplatform.serialization messages is the consequence of a previous crash of KDevelop.
"kdevplatform.util: Path::init: invalid/unsupported Path encountered:  http://clang-tidy" => installing clang-tidy might eliminate this error.
Hunspell configuration appears to be broken on your system.
"/bin/sh: 1: indent: not found" => either install GNU indent or (better) configure source formatters to match your project's code style in KDevelop settings.
"kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>" - this looks bad. Have you uninstalled some KDevelop language plugin? Does KDevelop parse your source code successfully?

Igor Kushnir wrote on 8/11/23 06:47:

> 
> The error messages have different causes. Some of them are probably not
> KDevelop's fault, but something's wrong on your system.

The system is a clean debian bookworm system, on which kdevelop was installed 
for the first time a week or so ago. Which doesn't mean that there might not 
be a debian packaging error that might cause problems; but I have not 
personally done anything to the system that would cause any instability.

> The kdevplatform.serialization messages is the consequence of a previous crash
> of KDevelop.
> "kdevplatform.util: Path::init: invalid/unsupported Path encountered:
> http://clang-tidy" => installing clang-tidy might eliminate this error.

I will try that. It's a bit surprising that debian doesn't automatically 
install clang-tidy as a dependency when it installs kdevelop.

> Hunspell configuration appears to be broken on your system.

I've never knowingly used hunspell. Presumably, debian auto-installed it in a 
broken way as a required dependency of some other package that's installed. 
I'll try to figure out what is wrong and, if I can, file a packaging bug 
report with debian.

> "/bin/sh: 1: indent: not found" => either install GNU indent or (better)
> configure source formatters to match your project's code style in KDevelop
> settings.

I don't understand the last part of that sentence (starting with the word 
"configure"). But in the meantime I'll install GNU indent when I have time 
(probably not today).

> "kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>" - this
> looks bad. Have you uninstalled some KDevelop language plugin? Does KDevelop
> parse your source code successfully?
> 

I have not uninstalled anything related to kdevelop. (Indeed, I don't think 
I've uninstalled anything at all since bookworm was installed).

kdevelop does mostly seem to parse the code correctly. Every now and then 
(maybe once a day) I see a red message on the screen that isn't right 
(flagging a line as having a problem when in fact it doesn't), but the few 
messages that I've seen have been related to new features in C++20, and I 
could easily believe that they're due simply to the installed parser not being 
quite up to date.

Thank you for your help and advice.

   Doc

(In reply to doc.evans from comment #4)
> > "/bin/sh: 1: indent: not found" => either install GNU indent or (better)
> > configure source formatters to match your project's code style in KDevelop
> > settings.
> 
> I don't understand the last part of that sentence (starting with the word 
> "configure"). But in the meantime I'll install GNU indent when I have time 
> (probably not today).
Go to KDevelop main menu=>Settings=>Configure KDevelop...=>Source Formatter. For each language you use, select a formatter and style that match your codebase's code style or your preferred code style. When KDevelop inserts or modifies code, it is formatted in the way configured here. Note that the formatter and style selected for the "C" language is applied to files with the extension "*.h", even if these files are in fact C++ headers.

"kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>" - I get these warnings occasionally too. They can be reproduced by running KDevelop using the command line
    KDEV_CLANG_DISPLAY_DIAGS=1 CLEAR_DUCHAIN_DIR=1 kdevelop
; including <bits/stdc++.h> in a single-file hello-world C++ project, selecting "c++2a" C++ profile and "GCC" as Compiler for path on the project's Language Support configuration page.

This is apparently missing implementation: CXType_Dependent is not handled in plugins/clang/duchain/builder.cpp (in Visitor::makeType() and Visitor::createType()). Unfortunately, I don't know how to add support for dependent types.

Some further background and information that may or may not be helpful.

1. I have installed clang-tidy; it makes no difference to the frequency of 
crashing, but the messages written on the terminal are reduced. Which I think 
is what you expected. The latest crash (a couple of minutes ago) produced merely:

----

n7dr@shack20:~/projects/drlog$ kdevelop
Qt WebEngine seems to be initialized from a plugin. Please set 
Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before 
constructing QGuiApplication.
Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed
kf.kio.workers.file: copy() 
QUrl("file:///home/n7dr/projects/drlog/drlog.kdev4") to 
QUrl("file:///tmp/kdevelop.aLZWfM") mode= -1
kf.kio.workers.file: the file doesn't have any xattr
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
kdevelop.plugins.clang: Unhandled type: Dependent <dependent type>
munmap_chunk(): invalid pointer
Aborted (core dumped)
n7dr@shack20:~/projects/drlog$

----

2. The crashes occur at the rate of about two per hour... I can get work done, 
but it's certainly annoying to be interrupted by crashes so frequently.

3. I have not found a particular sequence of actions that is guaranteed to 
reproduce the crash.

4. I *think* that crashes happen only when I've actively interacted with the 
editor window: either I'm in the middle of typing, or at the very least, I've 
just clicked somewhere in the window.

5. FYI, the project I'm working on is: https://github.com/N7DR/drlog.

   Doc

The QAccessible crash should be discussed in Bug 447740. It affects many KDevelop users, but never happens to most active KDevelop developers. Getting the crash fixed requires either that it becomes reproducible by KDevelop developers or that an affected user investigates and finds the root cause or a workaround.