https://bugs.kde.org/show_bug.cgi?id=392336
Kevin Funk changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=392336
--- Comment #6 from christian tacke ---
Hi,
small update: it does not crash any more. I tried with KDevelop 5.2.3 on Fedora
and 5.3.0/1 AppImage on Ubuntu Xenial.
Sadly I did not manage to trace this problem to the clang calls - this would
have been
https://bugs.kde.org/show_bug.cgi?id=392336
--- Comment #5 from Milian Wolff ---
the code is in kdevelop/plugins/clang, but it's going to be interesting to
figure out what we are actually all calling here, and in what threads.
if you want to track this down, it would be cool if
https://bugs.kde.org/show_bug.cgi?id=392336
--- Comment #4 from christian tacke ---
Hi Millian,
thank you for the clarification. If KDevelops stack / memory is corrupted
there's nothing to be done. I understand.
I ran the commands on another system with clang 3.8 and there
https://bugs.kde.org/show_bug.cgi?id=392336
--- Comment #3 from Milian Wolff ---
The problem really is that the built-in crash "recovery" in llvm/clang is not
bullet-proof. While it catches the crash signal to output this message, the
data afterwards can be corrupt and crash
https://bugs.kde.org/show_bug.cgi?id=392336
--- Comment #2 from christian tacke ---
Hello Sven,
I'll do that. But still KDevelop should not crash if possible.
It seems to me that libclang does itself some magic when it crahes so it can
generate this fancy output.
Between
https://bugs.kde.org/show_bug.cgi?id=392336
Sven Brauch changed:
What|Removed |Added
CC||m...@svenbrauch.de
---