Summary: | kdevelop : crash after hitting enter in code editor | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-ktexteditor | Reporter: | RJVB <rjvbertin> |
Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | kde, mail |
Priority: | NOR | Keywords: | drkonqi |
Version: | 5.38.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | All | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
RJVB
2017-10-05 13:27:55 UTC
Turns out this is reproducible: - Use the proposed "recover data" feature after reopening the session and parsing stopped. - hit enter after the new line The line in question, in DocumentationController::documentationProviders(): qWarning() << Q_FUNC_INFO << "Current documentation providers:" << ret; inserted before the return statement, with an empty line above and below the qWarning line. The crash disappears after reverting to KTextEditor 5.35.0 . *** This bug has been marked as a duplicate of bug 384404 *** OK, now I'm curious. The stack backtrace in 384404 doesn't look like the one I get at all, at least not the part in QtQML. How can you know it's the same bug? It'd be extremely nice if there were a workaround/fix for this, applicable either to KTextEditor or to Qt < 5.9 . 5.9 drops support for older OS versions on Mac. FWIW, this is what I get on Linux: Program received signal SIGSEGV, Segmentation fault. 0x00007fffce25dd77 in ?? () (gdb) bt #0 0x00007fffce25dd77 in ?? () #1 0x0000000000fc6a40 in ?? () #2 0x0003200000000000 in ?? () #3 0x00007fffbd54f540 in ?? () #4 0x0000000000fc6a40 in ?? () #5 0x0000000000fc6a40 in ?? () #6 0x00007ffff244d108 in getValue (attrs=..., v=..., this=0xfc6a40) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/jsruntime/qv4object_p.h:230 #7 QV4::Object::internalGet (this=0xfc6a40, name=0x7fffbd54f548, hasProperty=0x7fffbd54f418) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/jsruntime/qv4object.cpp:629 #8 0x00007ffff2419553 in get (hasProperty=0x7ffff2863d60 <QV4::CallContext::static_vtbl>, name=0x7fffbd54f4a0, this=<optimised out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/include/QtQml/5.8.0/QtQml/private/../../../../../src/qml/jsruntime/qv4object_p.h:326 #9 QV4::ExecutionContext::getPropertyAndBase (this=0x7fffbd54f418, name=0x7fffbd54f4a0, base=0x0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/jsruntime/qv4context.cpp:509 #10 0x00007ffff24a4273 in call (d=0x7fffbd54f458, scope=..., this=<optimised out>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/jsruntime/qv4object_p.h:352 #11 QV4::Runtime::method_callActivationProperty (engine=<optimised out>, nameIndex=<optimised out>, callData=0x7fffbd54f458) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtdeclarative/src/qml/jsruntime/qv4runtime.cpp:982 #12 0x00007fffce2a1956 in ?? () #13 0x0000000000000001 in ?? () #14 0x0000000000000000 in ?? () I guess simply because it's very unlikely there are two crash bugs in QtScript which trigger when pressing enter in kate. Yeah, that was my null hypothesis too, but I was kind of hoping it'd be wrong. This irks me, I cannot help but feel that it ought to be possible to tweak the "incriminated" QML function so that it doesn't trigger the bug. I'd tinker with that, but don't have an inkling where even to start. I'm now figuring out a patch that will revert KTextEdit to something that works with Qt 5.7 and 5.8, in hopes it'll be useful for others too. It seems one just has to revert #fc510adaecf1dc83416eaf4392925ee4f3c5a1e0 and then #878797830dbd3b29bd5dcd8241c17ea20fb6914e ... crossing fingers, toes and eyes they'll keep applying (mostly) cleanly until I get to update to Qt 5.9 . What makes you think the issue is solved in 5.9? Have you tried? No, I haven't, it's a conclusion drawn on the linked bug report (384404) |