Bug 371645

Summary:	"Program received signal SIGSEGV, Segmentation fault" while idle
Product:	[Applications] kdevelop	Reporter:	redmaw
Component:	general	Assignee:	kdevelop-bugs-null
Status:	RESOLVED WORKSFORME
Severity:	crash	CC:	mail, master.haber
Priority:	NOR
Version First Reported In:	5.0.2
Target Milestone:	---
Platform:	Appimage
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description redmaw 2016-10-25 03:57:03 UTC

The appimage segfaults - not sure if there is a any specific trigger. I have seen it segfault while in use but it will also crash if it is just left running.

OS: SLES11

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe488a720 (LWP 39720)]
0x00007ffff761ead3 in std::__atomic_base<int>::operator++ ()
   from /nfs/fm/proj/mpg/sa_csv_vjt_03/parkerer/kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5Crash.so.5

Stack trace:
#0  0x00007ffff761ead3 in std::__atomic_base<int>::operator++ ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5Crash.so.5
#1  0x00007ffff5ba9cfd in QAtomicOps<int>::ref<int> ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#2  0x00007ffff5ba8eb0 in QBasicAtomicInteger<int>::ref ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#3  0x00007ffff5bb0224 in QSharedPointer<Kate::TextLineData>::ref ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#4  0x00007ffff5baee27 in QSharedPointer<Kate::TextLineData>::QSharedPointer ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#5  0x00007ffff5babc59 in Kate::TextBlock::line ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#6  0x00007ffff5ba4e79 in Kate::TextBuffer::line ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#7  0x00007ffff5c3b478 in KateBuffer::plainLine ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#8  0x00007ffff5c1bb65 in KTextEditor::DocumentPrivate::textLines ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5TextEditor.so.5
#9  0x00007fffc87f857e in ClangParseJob::ClangParseJob ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/qt5/plugins/kdevplatform/25/kdevclangsupport.so
#10 0x00007fffffffc340 in ?? ()
#11 0x00007fffdfe87a88 in ?? ()
#12 0x00007fffad3442d0 in ?? ()
#13 0x0000000057ec4834 in ?? ()
#14 0x00007fffffffc380 in ?? ()
#15 0x00007fff0110b52b in ?? ()
#16 0x00007fffffffc330 in ?? ()
#17 0x00007fffffffc320 in ?? ()
#18 0x00007fffffffc300 in ?? ()
#19 0x00007fff93206288 in ?? ()
#20 0x00007fff93acefa0 in ?? ()
#21 0x00007fffffffc600 in ?? ()
#22 0x00007fffffffc360 in ?? ()
#23 0x00007fff93206260 in ?? ()
#24 0x00007fff0011175d in ?? ()
#25 0x00007fffdc000020 in ?? ()
#26 0x00007fffaccf1840 in ?? ()
#27 0x0000000000000078 in ?? ()
#28 0x00007fffde0b8690 in ?? ()
#29 0x0000000000000080 in ?? ()
#30 0x00000000013e90f0 in ?? ()
#31 0x00007fffdc000058 in ?? ()
#32 0x00000000013e23d0 in ?? ()
#33 0x0000000000000020 in ?? ()
#34 0x00007fff93be0650 in ?? ()
#35 0x00007fffdc000028 in ?? ()
#36 0x00007fff93acef80 in ?? ()
#37 0x00007ffff1b029f3 in QListData::detach_grow ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libQt5Core.so.5
#38 0x0000000000f75dc0 in ?? ()
#39 0x00007fff93206260 in ?? ()
#40 0x00007fffffffc600 in ?? ()
#41 0x00007fffffffc550 in ?? ()
#42 0x00007fffffffc540 in ?? ()
#43 0x00007fffffffc4e0 in ?? ()
#44 0x00007fffc8801276 in ClangSupport::createParseJob ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/qt5/plugins/kdevplatform/25/kdevclangsupport.so
#45 0x00007fffed824242 in KDevelop::BackgroundParserPrivate::createParseJob ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKDevPlatformLanguage.so.10
#46 0x00007fffed825e8b in KDevelop::BackgroundParserPrivate::parseDocumentsInternal ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKDevPlatformLanguage.so.10
#47 0x00007fffed81fa34 in KDevelop::BackgroundParser::parseDocuments ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKDevPlatformLanguage.so.10
#48 0x00007fffed9a1dc5 in KDevelop::BackgroundParser::qt_static_metacall ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKDevPlatformLanguage.so.10
#49 0x00007ffff1c95c01 in QObject::event ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libQt5Core.so.5
#50 0x00007fff92958b30 in ?? ()
#51 0x0000000000621ef0 in ?? ()
#52 0x0000000000883870 in ?? ()
#53 0x0000000000000000 in ?? ()
#0  0x00007ffff761ead3 in std::__atomic_base<int>::operator++ ()
   kdevelop5/KDevelop-5.0.1-x86_64/usr/lib/libKF5Crash.so.5

Reproducible: Always

Steps to Reproduce:
1. Run the appimage and wait.

Comment 1 Sven Brauch 2016-10-28 15:01:57 UTC

This crash is not while idle; it's in the background parser. Which project(s) did you load?

Comment 2 redmaw 2016-10-29 03:44:41 UTC

I had custom cmake projects with C++ and python open.

You are right in that it was not idle, but at the time I filed the bug I couldn't think of a better way to indicate the problem was not a result of direct user action.

Comment 3 Sven Brauch 2016-10-29 08:40:28 UTC

Are the projects available somewhere so I could load them and see if I can reproduce the crash?

Comment 4 redmaw 2016-10-29 23:44:27 UTC

No, unfortunately this is not an open source project (I don't own the rights). I will get some open source projects and report back on if KDevelop still crashes with them.

Comment 5 redmaw 2016-11-06 05:15:36 UTC

Something changed in my environment that prevents me from running the AppImage now so I think it will be best to close this as I can't reproduce it either. 

I will work on the issue eventually probably but it will be at least a few weeks until I get around to it. 

kdevelop: symbol lookup error: /usr/lib64/libGL.so.1: undefined symbol: _glapi_Dispatch

Comment 6 Sven Brauch 2016-11-06 10:32:53 UTC

Did we break that between 5.0.1 and 5.0.2 ...?

Comment 7 redmaw 2016-11-08 01:50:35 UTC

No, I never changed the AppImage so it is definitely something that change on my end. I'll get to it eventually but in the meantime I was able to generate a segfault while parsing the Linux kernel source as test on another system so see if that works for you.

Comment 8 Ian H 2016-11-08 15:17:46 UTC

i have noticed it 'randomly' crashing on my appimage as well. it seems to do it right after changing something in the code, but i cant get any backtrace, it seems there is a corrupt stack or something. It crashes at least once per hour at the moment, but it didnt do this before. sometimes though it doesnt even require me to change something, simply highlighting a section of code will crash it.

Thread 1 "kdevelop" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 24312]
0x7c240d7d in ?? ()
(gdb) bt
#0  0x7c240d7d in ?? ()
Backtrace stopped: Cannot access memory at address 0xf393b450

I also ran into an issue where the appimage wouldnt open and just instantly segfaults, deleting the cache didnt seem to change that, but rebooting did.

Comment 9 Ian H 2016-11-09 16:12:39 UTC

it does not seem to happen to me at all when using a built version of master instead of the appimage.

Comment 10 redmaw 2016-11-10 06:07:20 UTC

I have used the AppImage on a modern linux distro and do not have any problems. The code base is very small for that project though so the background parse does not run much (only a couple threads too).

Back trace for the crash when parsing the linux kernel source:

(gdb) bt
#0  0x00007fffacfd9e8c in clang::analyze_format_string::ArgType::matchesType ()
   from kdevelop5/KDevelop-5.0.2-1-x86_64/usr/lib/libclang.so.3.8
#1  0x000000000aa977c9 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000009d676e0 in ?? ()
#4  0x00007fffac4198b8 in (anonymous namespace)::CheckScanfHandler::HandleScanfSpecifier ()
   from kdevelop5/KDevelop-5.0.2-1-x86_64/usr/lib/libclang.so.3.8
#5  0x00007fffacfe2c98 in clang::analyze_format_string::ParseScanfString ()
   from kdevelop5/KDevelop-5.0.2-1-x86_64/usr/lib/libclang.so.3.8
#6  0x00007ffff1253ec8 in main_arena () from /lib64/libc.so.6
#7  0x00000000049df6d0 in ?? ()
#8  0x00007fffced4c0e0 in ?? ()
#9  0x0000000100000050 in ?? ()
#10 0x0000000004a3f3e0 in ?? ()
#11 0x00007fffced4c170 in ?? ()
#12 0x0000000000000000 in ?? ()

Comment 11 Sven Brauch 2016-11-10 07:49:18 UTC

That is unrelated to the original issue and looks very much like a bug in libclang. It should be reported (and fixed) there.

Comment 12 redmaw 2016-11-11 04:48:27 UTC

Okay, looks I need to continue to try and reproduce the original issue.

Comment 13 Justin Zobel 2020-12-17 05:23:50 UTC

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Comment 14 redmaw 2020-12-19 00:32:36 UTC

Have not seen in this issue in years so changing to resolved/worksforme.