| Summary: | kdevelop always crashes when opening a certain project | ||
|---|---|---|---|
| Product: | [Developer tools] kdev-python | Reporter: | Salvo "LtWorf" Tomaselli <tiposchi> |
| Component: | Language support | Assignee: | Sven Brauch <mail> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | jonathan.verner, mail, mail |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 5.3.1 | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Salvo "LtWorf" Tomaselli
2019-01-11 10:58:32 UTC
@Francis this looks like the issue you fixed recently ...? I don't think it is, there's no annotated assignment in the call stack...
Looks similar, though.
To the reporter:
Thanks for the report.
The crash is in the Python parser, probably triggered by some specific combination of syntax.
If you run `export QT_LOGGING_RULES="kdevelop.plugins.python=true"` before starting KDevelop, it will print (among other things) lines of the format
`kdevelop.plugins.python: ====> PARSING ====> parsing file QUrl("file:///home/flh/foo.py") ; has priority -10000`
This should identify the file being parsed at the time of the crash.
The call stack in your crash report should help find the specific part responsible; it involved:
- An attribute access
- Inside a list comprehension
- As part of a function call (either as an argument, or the thing being called)
- At the top level of a function body.
If you can produce a minimal example (perhaps with variable names etc. anonymized) that would help identify and fix the problem.
Note: I have tried to reproduce the issue just by looking at the call stack, but without success so far.
Created attachment 117409 [details]
New crash information added by DrKonqi
kdevelop (5.3.1) using Qt 5.11.2
Editing the following python code:
from typing import Dict, Iterable, List, Optional, Tuple, Union
class Comment:
pass
class Lexeme:
pass
class LexicalUnit:
pass
class LexemeCollection:
def __init__(self, lexemes: Optional[Iterable[Lexeme]] = None):
self._lexemes: Dict[str, Lexeme] = {lex._id: lex for lex in lexemes}
self._lexical_units = {lu._id: lu for lu in sum([lex._lexical_units for lex in lexemes], [])}
reliably leads to a crash
-- Backtrace (Reduced):
#6 0x00007f4aeaa2b280 in Python::UseBuilder::contextAtOrCurrent(KDevelop::CursorInRevision const&) () at /lib/x86_64-linux-gnu/libkdevpythonduchain.so
#7 0x00007f4aeaa2c272 in Python::UseBuilder::visitName(Python::NameAst*) () at /lib/x86_64-linux-gnu/libkdevpythonduchain.so
#8 0x00007f4aebbbbed6 in Python::AstDefaultVisitor::visitAttribute(Python::AttributeAst*) () at /lib/x86_64-linux-gnu/libkdevpythonparser.so
#9 0x00007f4aeaa2bd26 in Python::UseBuilder::visitAttribute(Python::AttributeAst*) () at /lib/x86_64-linux-gnu/libkdevpythonduchain.so
#10 0x00007f4aebbbd076 in Python::AstDefaultVisitor::visitDictionaryComprehension(Python::DictionaryComprehensionAst*) () at /lib/x86_64-linux-gnu/libkdevpythonparser.so
Thanks for the reduced example! Now I'm a bit puzzled... The example in your last comment is (like Sven suspected before) an instance of https://bugs.kde.org/show_bug.cgi?id=403045 , which should be fixed by the patch linked in that bug. My concern is that your original backtrace still *doesn't* look like an instance of that bug to me, thus it's possible that you've been unlucky and encountered two different ones. Can you please try with the patch from above (or just 5.3-git) and see if it does solve your original problem? Thanks again, and sorry for the bugs... > My concern is that your original backtrace still *doesn't* look like an instance of that bug to me, thus it's possible that you've been unlucky and encountered two different ones. I am sorry for the confusion I probably caused. I am not the original reporter of this bug, its just that drKonqui directed me to this bug which seemed to have a very similar backtrace, so I added my comments here... > Can you please try with the patch from above (or just 5.3-git) and see if it does solve your original problem? The kdevelop-git appimage indeed does not crash on my reduced example. But again, I am not sure about the originally reported case by Salvo > Thanks again, and sorry for the bugs... Thank you for working on this excellent IDE!! Sorry, I should have noticed the different names. In that case, I'm fairly certain the original bug is a different one. - Salvo: Please try to add a reduced code example using my steps from Comment #2 above; I still haven't been able to reproduce the bug from only the backtrace. I ran it with the debug option a couple of times, and the last file before the crash was not the same in both cases. In one case it was a py file in /usr, so it can't be that or it would always crash. Anyway I had tried to bisect and delete files to figure out the responsible one, and I failed to locate a single file that causes the crash. It looks more like a combination of more files. Thank you for making the effort! As a parser crash, I think it's unlikely that multiple files are involved. It's possible that, with multiple parser threads running, the last filename printed could be from a different thread than the one that crashes. (sorry, I should have considered that in my earlier suggestions) You might try setting `Configure KDevelop -> Background Parser -> Maximum number of threads` to 1, or simply looking at the last 3 or 4 filenames to see if any are consistent. Re. files under /usr - it's possible that code in some library file causes the crash, if it's imported in this project but not in others that you've used KDevelop on. So I narrowed it down to this function.
I guess it's small and useless enough that I can publish it.
Also, I didn't write it, I'd never use set() on a list comprehension :D
def is_environment_complete(environment: Environment, scenario: Scenario) -> bool:
current_nodes = environment.nodes
current_node_names = set([n.name for n in current_nodes])
current_node_roles: Set[str] = set(sum([n.roles for n in current_nodes], []))
expected_nodes = scenario.nodes
expected_node_names = set([n.name for n in expected_nodes])
expected_node_roles: Set[str] = set(sum([n.roles for n in expected_nodes], []))
return current_node_names == expected_node_names and current_node_roles == expected_node_roles
Aaagh. Thanks again for your work. I can reproduce the crash with your example in 5.3.1; I'm afraid it does seem to be another instance of https://bugs.kde.org/show_bug.cgi?id=403045 (which I fixed last week). I still can't see how the annotated assignment doesn't appear in your original backtrace, so it's barely possible there's a second bug, but all the rest of the AST appears to match. I'm going to close this as a duplicate of the linked bug for now. If it recurs with kdev-python 5.3-git, 5.3.2 when that's released, or 5.3.1 with the one-line patch from the linked bug, please reopen. *** This bug has been marked as a duplicate of bug 403045 *** |