[kdevelop] [Bug 363237] Breakpoints (Breakpoints View) are not updated after removing/adding couple lines of code
https://bugs.kde.org/show_bug.cgi?id=363237 --- Comment #7 from Axel Kellermann --- See my comment in the MR mentioned above: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 BreakpointModel already contains all the logic needed to resolve the issue. What's missing is an appropriate event to react on. And as remarked by Igor, it would probably also be a good idea to refactor the code in BreakpointModel a bit to prevent a potential negative impact on performance. Maybe one of the more senior KDE/KDevelop devs could have a look at my comment in the MR and assess if my statement makes sense and how it could be implemented. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363237] Breakpoints (Breakpoints View) are not updated after removing/adding couple lines of code
https://bugs.kde.org/show_bug.cgi?id=363237 Axel Kellermann changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||axel.kellerm...@gmx.de --- Comment #5 from Axel Kellermann --- (In reply to Igor Kushnir from comment #4) > (In reply to Piotr Mierzwinski from comment #3) > > Fixed in Bug 424431 > Are you sure this bug is really fixed already? Even with the fix for Bug > 424431, Breakpoints view only synchronizes when the document is saved. See > https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147#note_89877 This issue is definitely not resolved. Reopening it. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 424431] Loaded breakpoints don't update properly if code is edited
https://bugs.kde.org/show_bug.cgi?id=424431 --- Comment #1 from Axel Kellermann --- https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 424430] Loaded breakpoints don't show up in UI
https://bugs.kde.org/show_bug.cgi?id=424430 --- Comment #1 from Axel Kellermann --- See https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/147 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 424431] New: Loaded breakpoints don't update properly if code is edited
https://bugs.kde.org/show_bug.cgi?id=424431 Bug ID: 424431 Summary: Loaded breakpoints don't update properly if code is edited Product: kdevelop Version: 5.5.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: UI: general Assignee: kdevelop-bugs-n...@kde.org Reporter: axel.kellerm...@gmx.de Target Milestone: --- SUMMARY Breakpoints that were loaded with the project don't get properly updated if source code is edited. STEPS TO REPRODUCE 1. Open project 2. Set breakpoints 3. Close project 4. Open project again 5. Add or remove lines in the source code OBSERVED RESULT Breakpoint positions are not properly updated in BreakpointModel and therefore in Breakpoint Tool View. EXPECTED RESULT Proper updates of breakpoints. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I have a fix for that issue locally, going to send it in for review the coming days. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 424430] New: Loaded breakpoints don't show up in UI
https://bugs.kde.org/show_bug.cgi?id=424430 Bug ID: 424430 Summary: Loaded breakpoints don't show up in UI Product: kdevelop Version: 5.5.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: UI: general Assignee: kdevelop-bugs-n...@kde.org Reporter: axel.kellerm...@gmx.de Target Milestone: --- SUMMARY Loaded breakpoints don't show up in the UI. STEPS TO REPRODUCE 1. Open project 2. Set breakpoints 3. Close project 4. Load project again OBSERVED RESULT UI does not show breakpoint markers in the text editor view, but breakpoints are correctly shown in the Breakpoints Toolview. EXPECTED RESULT UI shows breakpoint markers. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I have a fix for that locally, I'll send it in for review the coming days. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 405221] Faulty code parsing with Clang backend
https://bugs.kde.org/show_bug.cgi?id=405221 Axel Kellermann changed: What|Removed |Added CC||axel.kellerm...@gmx.de --- Comment #2 from Axel Kellermann --- See https://phabricator.kde.org/D23303 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 321982] Clicking on cmake error line does not open the corresponding file
https://bugs.kde.org/show_bug.cgi?id=321982 Axel Kellermann <axel.kellerm...@gmx.de> changed: What|Removed |Added CC||axel.kellerm...@gmx.de --- Comment #8 from Axel Kellermann <axel.kellerm...@gmx.de> --- I had a look at this issue and the solution proposed before. I think the easiest and least invasive way to fix this is to just filter the project directory out of the cmake output. The code change is minimal and just a couple of lines long. I also tried to cover Windows paths in the regex, but I don't have a system to test this properly. For my patch proposal see: https://phabricator.kde.org/D7040 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 323337] Kdevelop crashes on reformat wrong preprocessor macro
https://bugs.kde.org/show_bug.cgi?id=323337 Axel Kellermann <axel.kellerm...@gmx.de> changed: What|Removed |Added CC||axel.kellerm...@gmx.de --- Comment #5 from Axel Kellermann <axel.kellerm...@gmx.de> --- Followed the steps to reproduce with current master and wasn't able to trigger the described crash. Also tried a couple of file types (C, C++) with different formatters. Either some prerequisite to trigger the crash wasn't mentioned in the steps to reproduce, or the crash got fixed by some other changes made since ticket creation (almost four years ago). -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #32 from Axel Kellermann <axel.kellerm...@gmx.de> --- (In reply to Sven Brauch from comment #31) > Ah yes, if you trick the mimetype detection, you will still crash. You are > also right about strncpy. > > phabricator should be simple enough to use, just log in (with > identity.kde.org), click differential, then click new diff and paste your > diff. OK, I added the diff to phabricator: https://phabricator.kde.org/D6924 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #30 from Axel Kellermann <axel.kellerm...@gmx.de> --- (In reply to Sven Brauch from comment #28) > Patch still looks sensible to me -- maybe use strncpy instead, and put it on > phabricator.kde.org so somebody familiar with the code can have a look? strncpy()/strndup() won't work either. Both copy up to n bytes, but also end processing on the occurence of the first '\0' (at least to my understanding). I'll have a look at phabricator. Never used it before... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #29 from Axel Kellermann <axel.kellerm...@gmx.de> --- (In reply to Sven Brauch from comment #27) > Does that still happen with KDevelop 5.1+? I thought I fixed it. See comment #22. Random .txt files aren't scanned anymore, but .cmake files can still trigger the faulty behaviour. I conducted my tests with cmListFileLexer.c from master (last updated beginning of the week). But I extracted it into a small reproducer application to ease debugging, so if you fixed it somewhere in the cmake parser outside of cmListFileLexer.c, maybe we don't have to do anything. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #26 from Axel Kellermann <axel.kellerm...@gmx.de> --- I had another look at the lexer and I think I pinned down the problem with UTF-16 files in cmListFileLexer.c. Scanning the files works fine, but copying the scanned content into the token structure in cmListFileLexerSetToken() is where things go wrong. The code that copies the content uses the functions strcpy() and strdup() that are meant to be used only with zero-terminated character arrays. As we handle two-byte characters, where the most significant byte can be zero (see e.g. letter 'h' with 0x0068), it's possible that the text to be copied to token->text contains zero-bytes mid-string. In that case strdup() doesn't do what it's intended to do. It interprets the buffer as zero-terminated string and only duplicates it up to the first occurence of '\0'. At the same time the original buffer size is stored in token->length. This leads to out-of-bounds memory accesses later on. I attached a simple UTF-16 file that reliably triggers the problem for me (363269_repro.txt) and a proposal for a fix that replaces the string functions with mallocs/memcpys (363269_proposal.patch). Maybe someone with more experience with the cmake parser/lexer could have a look at it. Related questions: The patch fixes the crashes/ASAN aborts for me, but is the cmake parser really handling UTF-16 files correctly? Functions like cmListFileLexer_BOM() imply that it can handle all kinds of UTF formats, but at the same time the whole code seems to imply that it only works on zero terminated char arrays. Do we possibly need to update to a newer version of the lexer (which is generated from external sources, right?)? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #25 from Axel Kellermann <axel.kellerm...@gmx.de> --- Created attachment 106866 --> https://bugs.kde.org/attachment.cgi?id=106866=edit Proposal for patch -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken, CMakeListsParser::readCMakeFile]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #24 from Axel Kellermann <axel.kellerm...@gmx.de> --- Created attachment 106865 --> https://bugs.kde.org/attachment.cgi?id=106865=edit Minimal UTF-16 file to trigger behavior -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 363269] Crash when projects contains *.txt file that is actually a binary file [cmListFileLexerSetToken]
https://bugs.kde.org/show_bug.cgi?id=363269 --- Comment #19 from Axel Kellermann <axel.kellerm...@gmx.de> --- I had some time to kill today, so I took another look at why random .txt files get processed by the background parser. If I understand the code flow correctly, it happens like this: - on startup the project folder is recursively scanned for all contained files - every found file is wrapped in a ProjectFileItem (abstractfilemanagerplugin.cpp:234) and added to the projects file set - the BackgroundParser then creates a ParseJob for every ProjectFileItem (in BackgroundParser::parseDocumentsInternal()) - in BackgroundParser::createParseJob(), the language to use for the current ProjectFileItem is queried by a call to m_languageController->languagesForUrl(qUrl) - LanguageController::languagesForUrl() in turn checks an internal mimeTypeCache and fileExtensionCache for the language to use for the given file - in my case, the fileExtensionCache contains an entry that resolves the extension txt to language CMake - that means in backgroundparser.cpp:357 I get back a CMakeManager, that is then used to create a cmake parse job Is that expected behaviour or some side effect that has to be fixed? I'm asking this because there are multiple cmake specific spots in the code that explicitly filter for "CMakeLists.txt" and "*.cmake", and that are circumvented by this implicit behaviour. -- You are receiving this mail because: You are watching all bug changes.
