https://bugs.kde.org/show_bug.cgi?id=385640
--- Comment #6 from Kevin Funk <kf...@kde.org> --- > Have you read the ticket and commit message? I cannot reproduce the issue at > will either. It happens and *will* (always?) provoke a crash, but it does so > seemingly randomly. Yes. It told me you haven't fully understood the problem and you're adding hacks which inevitably may cause other crashes (i.e. when DocumentationView is being destructed again, trying to cleanup resources which were never initialized properly). > If you want to run each and every KDevelop session under a debugger with a > breakpoint set, be our guest (our as in everyone using the app). I don't have > the resources for that. What's the problem with running it under GDB? Not having the resources for that is not an excuse if you want to actively develop and file patches for a project. > I don't agree with your analysis in this case. There's no point in setting up > a DocumentationView when the application is exitting. I don't or didn't concur with that. > Nothing done in that ctor is crucial unless you use the instance, and that's > not going to happen. And you know that it isn't used based on...? How can you know it's not being used if you don't know where/when the class is being instantiated? > Alternatively, please provide a utility to print a backtrace in ICore or > wherever appropriate if there isn't already. I'll use that to determine where > the call comes from. https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for "backtrace" -- you can enable them for e.g. warnings exclusively. > (Yes, I could write such a utility class myself but this time I'm going to > leave it to some of the powers that be who don't need drawn-out review > procedures.) I see what you're hinting at. Please note that "drawn-out" review procedures are only necessary in "special cases". It's definitely not happing for the majority of incoming reviews for KDevelop. The key point in not ending up with lengthy discussions in reviews is a) having a good understanding of the problem at hand before even trying put up patches for review, b) focusing on one issue at a time during discussions, c) posting a patch where you have good confidence that it is the right fix to begin with and not a series of obvious work-arounds. > Oh, and you could have left the secondary fix in that commit. Yes, or the original author could have at least committed that hunk separately, with a proper commit message explaining what this change does. -- You are receiving this mail because: You are watching all bug changes.
