https://bugs.kde.org/show_bug.cgi?id=370641
RJVB <rjvber...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kf...@kde.org See Also| |https://bugs.kde.org/show_b | |ug.cgi?id=363893 --- Comment #2 from RJVB <rjvber...@gmail.com> --- Found it, this is another example of the danger of using Q_ASSERT : ClangFixits ClangProblem::allFixits() const { ClangFixits result; result << m_fixits; for (const IProblem::Ptr& diagnostic : diagnostics()) { const Ptr problem(dynamic_cast<ClangProblem*>(diagnostic.data())); Q_ASSERT(problem); result << problem->allFixits(); } return result; } a dynamic_cast can fail even if diagnostic.data() != NULL, for instance because of (or related to) the issue reported in ticket 363893. When code is built in "production" mode, Q_ASSERTs are noops, and this leads directly to the crash and backtrace shown above. I cannot assess to what extent a NULL problem should cause KDevelop to abort. I am currently trying the fix below, and with that implementation I see exactly the same (popup error reporting) as I see on Linux. Curiously the warning hasn't been printed yet, even. ClangFixits ClangProblem::allFixits() const { ClangFixits result; result << m_fixits; for (const IProblem::Ptr& diagnostic : diagnostics()) { const Ptr problem(dynamic_cast<ClangProblem*>(diagnostic.data())); Q_ASSERT(problem); if (problem) { result << problem->allFixits(); } else { qWarning() << Q_FUNC_INFO << "dynamic cast to ClangProblem failed of" << diagnostic.data(); } } return result; } -- You are receiving this mail because: You are watching all bug changes.