Bug 233831

Summary: devel/llvm60: crash when parsing files through kdevelop
Product: Ports & Packages Reporter: Masse Nicolas <nicolas.masse>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: dim, freebsdbugs, koobs, tcberner, val
Priority: --- Keywords: crash, needs-qa
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233506

Description Masse Nicolas 2018-12-06 16:56:10 UTC 
When I open some projects in kdevelop, it crash when tryong to parse the file.
From a console, it seems that the bug is in fact located in libclang and is due to the following assertion:
Assertion failed: (DelayedTypos.empty() && "Uncorrected typos!"), function ~Sema, file /wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/tools/clang/lib/Sema/Sema.cpp, line 362.

using the generated kdevelop.core file, I get this:
 (included : the stacktrace of the 2 threads which seems to deal with parsing, the crash happens in thread 1)

Thread 13 (LWP 101061):
#0  0x0000000804d2366c in ?? () from /lib/libthr.so.3
#1  0x0000000804d1fcba in ?? () from /lib/libthr.so.3
#2  0x000000081a57b5ba in llvm::llvm_execute_on_thread(void (*)(void*), void*, unsigned int) () from /usr/local/llvm60/lib/../lib/libLLVM-6.0.so
#3  0x000000081a504bb0 in llvm::CrashRecoveryContext::RunSafelyOnThread(llvm::function_ref<void ()>, unsigned int) () from /usr/local/llvm60/lib/../lib/libLLVM-6.0.so
#4  0x0000000817713f8e in clang_parseTranslationUnit2FullArgv () from /usr/local/llvm60/lib/libclang.so.6
#5  0x0000000817713bd7 in clang_parseTranslationUnit2 () from /usr/local/llvm60/lib/libclang.so.6
#6  0x0000000817030764 in ParseSessionData::ParseSessionData(QVector<UnsavedFile> const&, ClangIndex*, ClangParsingEnvironment const&, QFlags<ParseSessionData::Option>) ()
   from /usr/local/lib/libKDevClangPrivate.so.30
#7  0x0000000816f6f76c in ?? () from /usr/local/lib/qt5/plugins/kdevplatform/30/kdevclangsupport.so
#8  0x00000008029df370 in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#9  0x00000008029dfa5c in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#10 0x00000008029de81f in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#11 0x00000008029de4bd in ThreadWeaver::Thread::run() () from /usr/local/lib/libKF5ThreadWeaver.so.5
#12 0x0000000802c5c02b in ?? () from /usr/local/lib/qt5/libQt5Core.so.5
#13 0x0000000804d15776 in ?? () from /lib/libthr.so.3
#14 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffde1ef000

Thread 1 (LWP 101064):
#0  0x00000008030a945a in thr_kill () from /lib/libc.so.7
#1  0x00000008030a7844 in raise () from /lib/libc.so.7
#2  0x000000080301a079 in abort () from /lib/libc.so.7
#3  0x00000008030972c1 in __assert () from /lib/libc.so.7
#4  0x0000000817b29eb3 in ?? () from /usr/local/llvm60/lib/libclang.so.6
#5  0x00000008179a3ee6 in ?? () from /usr/local/llvm60/lib/libclang.so.6
#6  0x0000000817708644 in clang_disposeTranslationUnit () from /usr/local/llvm60/lib/libclang.so.6
#7  0x0000000817032665 in ParseSessionData::~ParseSessionData() () from /usr/local/lib/libKDevClangPrivate.so.30
#8  0x000000081703271e in ParseSessionData::~ParseSessionData() () from /usr/local/lib/libKDevClangPrivate.so.30
#9  0x0000000816f703ac in ?? () from /usr/local/lib/qt5/plugins/kdevplatform/30/kdevclangsupport.so
#10 0x00000008029df370 in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#11 0x00000008029dfa5c in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#12 0x00000008029de81f in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /usr/local/lib/libKF5ThreadWeaver.so.5
#13 0x00000008029de4bd in ThreadWeaver::Thread::run() () from /usr/local/lib/libKF5ThreadWeaver.so.5
#14 0x0000000802c5c02b in ?? () from /usr/local/lib/qt5/libQt5Core.so.5
#15 0x0000000804d15776 in ?? () from /lib/libthr.so.3
#16 0x0000000000000000 in ?? ()
Comment 1 Brooks Davis freebsd_committer freebsd_triage 2018-12-06 22:12:58 UTC 
I'd suggest working with the upstream kdevelop team to see if they can help you produce a reduced test case to submit to upstream LLVM.  There is nothing I can do to help here except to suggest that you might try updating kdevelop to use llvm70 and seeing if the problem happens to have been fixed.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2018-12-07 09:02:33 UTC 
Apologies, did not mean to set Closed->FIXED.

Since we don't have a resolution like 'Send Upstream', and 'Rejected' (not accepted) isn't quite relevant (there was no proposal/patch) and not quite the same as WONTFIX, leave this Open for now.

CC'd Dimitry in case he's aware of a fix in subsequent versions, for which a backport/patch may be available to fix llvm60
Comment 3 Dimitry Andric freebsd_committer freebsd_triage 2018-12-07 12:29:17 UTC 
There have been quite a lot of similar-looking upstream bugs, but without a reproducible test case, it is hard to say if the problem is fixable.

Is there any way to get at a (preprocessed) version of the file that the parser crashes on?  E.g. you could attempt to run:

clang -cc1 -fsyntax-only

on the file in question.
Comment 4 Val Packett 2018-12-07 13:10:41 UTC 
We actually shouldn't have assertions enabled. Many dev tools (cquery/ccls, even clangd) trip clang assertions way too often. Linux distros and macOS don't ship assertions enabled. And no one actually intentionally enabled assertions in the FreeBSD port, it was a result of CFLAGS being set in the environment removing -DNDEBUG:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233506
Comment 5 Dimitry Andric freebsd_committer freebsd_triage 2018-12-07 21:14:28 UTC 
(In reply to Greg V from comment #4)
> We actually shouldn't have assertions enabled. Many dev tools (cquery/ccls,
> even clangd) trip clang assertions way too often. Linux distros and macOS
> don't ship assertions enabled.

While that is true, I do know that many LLVM assertions are indications of internal state going bad.  The builds with disabled assertions will then possibly segfault instead, or produce corrupted output.

That said, most users will care more for performance than consistency, so maybe turning assertions off is a good default choice.  We also do this in the base system's copy of LLVM, at least for releases (and IIRC also stable branches).
Comment 6 Val Packett 2018-12-07 21:37:50 UTC 
(In reply to Dimitry Andric from comment #5)
Yes, *LLVM* assertions can be helpful, but *libclang* seems way too assertion happy.

Turning them off in release mode is the choice LLVM developers made. And we *accidentally* override it because CMake is awesome™ :)
Comment 7 Masse Nicolas 2018-12-10 08:24:20 UTC 
(In reply to Dimitry Andric from comment #3)
Unfortunately, I can't give you a copy of the project.
I'm trying to see if I can find a reduced set of code which trigger the crash. I will let you know if I found one.
Comment 8 Tobias C. Berner freebsd_committer freebsd_triage 2020-08-02 10:13:36 UTC 
Moin moin 

This seems a bit stale. Feel free to reopen it, if it is still an issue with the llvm versions available in the ports tree at the moment.


mfg Tobias
Comment 9 Masse Nicolas 2020-08-03 08:48:48 UTC 
Last time I check I had not the issue anymore.
Also I was forced to change my desktop operating system so I'm not working on FreeBSD anymore (not my choice), so I'm not able to investigate this anymore :-/.