Bug 413364 - Crash when background parser is done/almost done
Summary: Crash when background parser is done/almost done
Status: REPORTED
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 5.3.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-23 12:23 UTC by Joachim Reichel
Modified: 2019-10-24 14:57 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Full backtrace (71.18 KB, text/plain)
2019-10-23 12:23 UTC, Joachim Reichel
Details
Repro case (decompresses to two files of almost one million lines and 76 MB each) (527.93 KB, application/gzip)
2019-10-24 14:57 UTC, Joachim Reichel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Reichel 2019-10-23 12:23:19 UTC
Created attachment 123440 [details]
Full backtrace

Qt Version: 5.11.3
Frameworks Version: 5.54.0
Operating System: Linux 4.19.0-6-amd64 x86_64
Distribution: Debian GNU/Linux 10 (buster)
Clang version (debian package version): 1:7.0.1-8

- What I was doing when the application crashed:

When I open a particular project, the background parser starts updating its
database. For a long time it shows 99% and one particular filename (I don't think it takes that long for that rather small file, I guess it just not
updating the window). Eventually, kdevelop crashes. I don't interact with kdevelop at that time at all.

The crash can be reproduced every time.

Full backtrace as attachment.

Thread 17 (Thread 0x7f931e7fc700 (LWP 1642)):
[KCrash Handler]
#6  0x0000000000002df1 in  ()
#7  0x00007f9336c05070 in operator() () at /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unique_ptr.h:81
#8  0x00007f9336c05070 in ~unique_ptr () at /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/unique_ptr.h:274
#9  0x00007f9336c05070 in ~ASTUnit() () at /build/llvm-toolchain-7-qQrbAC/llvm-toolchain-7-7.0.1/tools/clang/lib/Frontend/ASTUnit.cpp:272
#10 0x00007f9336c14582 in llvm::CrashRecoveryContextDeleteCleanup<clang::ASTUnit>::recoverResources() () at /build/llvm-toolchain-7-qQrbAC/llvm-toolchain-7-7.0.1/include/llvm/Support/CrashRecoveryContext.h:190
#11 0x00007f932cf4b701 in llvm::CrashRecoveryContext::~CrashRecoveryContext() () at /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#12 0x00007f93369ae688 in clang_parseTranslationUnit2FullArgv() () at /build/llvm-toolchain-7-qQrbAC/llvm-toolchain-7-7.0.1/tools/clang/tools/libclang/CIndex.cpp:3593
#13 0x00007f93369ae31f in clang_parseTranslationUnit2() () at /build/llvm-toolchain-7-qQrbAC/llvm-toolchain-7-7.0.1/tools/clang/tools/libclang/CIndex.cpp:3537
#14 0x00007f934495dc65 in ParseSessionData::ParseSessionData(QVector<UnsavedFile> const&, ClangIndex*, ClangParsingEnvironment const&, QFlags<ParseSessionData::Option>) () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.31
Comment 1 Joachim Reichel 2019-10-24 14:57:58 UTC
Created attachment 123460 [details]
Repro case (decompresses to two files of almost one million lines and 76 MB each)

The crash happens on one of two very large files that represent binary data as character array. Not sure whether it is relevant that both header files are included by a third file. The binary data is some fake data, but sufficient to reproduce the problem.